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ABSTRACT 

This  thesis  is  an  assessment  of  the  current  efforts  in  the  development  of  a  Marine 
Corps  Tactical  Command  and  Control  System  (MTACCS).  The  Marine  Corps  has  been 
developing  MTACCS  for  more  than  twenty  years.  The  recent  cancellation  of  a  key 
component  subsystem  and  the  DOD  reorganization  efforts  of  the  late  1980's  caused  a  two 
year  period  of  dormancy  in  this  program.  The  driving  goal  of  this  assessment  is  to 
develop  an  understanding  of  the  strengths  and  possible  risks  inherent  in  the  new 
"revitalized"  program  that  is  now  in  renewed  development.  The  assessment  effort 
examines  the  history  of  the  program,  the  feasibility  of  the  new  concept,  cost  effectiveness, 
systems  engineering,  and  interoperability.  Conclusions  stress  the  importance  of  doctrinal 
consensus,  adequate  requirements  definition,  engineering  the  system  as  a  whole,  and 
evolutionary  acquisition  of  modern  command  and  control  systems. 
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I.  INTRODUCTION 

A.      PURPOSE  OF  THE  THESIS 

This  thesis  is  an  assessment  of  the  current  efforts  in  the  development  of  a  Marine 
Corps  Tactical  Command  and  Control  System  (MTACCS).  The  United  States  Marine 
Corps  has  been  developing  MTACCS  for  more  than  twenty  years.  Several  significant 
events  in  the  mid  1980's  resulted  in  a  major  upheaval  within  the  Department  of  Defense 
and  a  subsequent  reevaluation  of  the  MTACCS  concept.  The  Goldwater-Nichols  Defense 
Reorganization  Act  of  1986  and  the  termination  of  a  key  MTACCS  subsystem  in  1987 
stand  out  as  the  most  vital  of  these  events.  While  development  on  other  MTACCS 
subsystems  continued,  only  nominal  integration  of  these  systems  was  achieved  between 
1988  and  1990.  The  concept  has  only  recently  been  "revitalized"  after  two  years  of 
dormancy.  [Ref.  1]  The  assessment  of  this  newest  version  of  MTACCS  will  be 
concerned  with  five  important  areas: 

1.  The  impact  of  the  termination  of  a  key  MTACCS  subsystem  for  command  and 
control  of  fire  and  air  support. 

2.  The  feasibility  of  the  new  MTACCS  concept. 

3.  The  cost-effectiveness  of  MTACCS. 

4.  Marine  Corps  combat  development  practices. 

5.  MTACCS  level  of  interoperability. 


The  driving  goal  of  this  assessment  is  to  develop  an  understanding  of  the  strengths 
and  possible  risks  inherent  in  the  new  MTACCS  concept.  Additionally,  recommendations 
are  proposed  that  offer  methods  of  mitigating  the  impact  of  identified  risk  factors. 

B.       OUTLINE  OF  THE  CHAPTERS 

1.  Chapter  II.   The  Termination  of  MIFASS 

The  Marine  Integrated  Fire  and  Air  Support  System  (MIFASS)  was  a  recent 
Marine  Corps  attempt  at  developing  a  key  MTACCS  component  subsystem  for  fire 
support.  The  MIFASS  program  was  canceled  in  1987  after  almost  twenty  years  in 
development.  One  result  of  the  termination  of  MIFASS  is  the  use  of  new  approaches  to 
the  development  and  acquisition  of  Command  and  Control  systems.  MTACCS  is  based 
on  these  new  ideas.  Chapter  II  details  the  difficulties  encountered  during  the  MIFASS 
program  that  ultimately  led  to  the  termination  of  the  project. 

2.  Chapter  III.  MTACCS  Today:  The  Response  to  MIFASS 

The  "revitalized"  concept  is  a  response  to  many  factors.  Important  among 
these  factors  is  the  termination  of  the  MIFASS  program.  Chapter  III  describes  the 
MTACCS  concept  as  it  is  currently  envisioned.  MTACCS,  however,  is  only  now  being 
defined.  Many  of  the  guiding  directives  and  strategy  documents  are  still  in  draft.  While 
the  basic  thrust  of  the  new  concept  is  stable,  some  changes  in  concept  definition  are 
occurring  even  as  this  thesis  is  being  written. 


3.  Chapter  IV.   Feasibility  Assessment 

The  implementation  of  MTACCS  is  an  extreme  challenge.  At  least  several  of 
the  objectives  of  MTACCS  fall  into  the  "high  risk"  category  and  may  be  difficult  to 
achieve  at  any  reasonable  cost  and  expenditure  of  effort.  The  first  assessment,  then,  is 
an  evaluation  of  the  feasibility  of  the  MTACCS  goals.  While  much  of  this  evaluation  is 
necessarily  subjective,  the  question  of  feasibility  must  be  addressed  regardless  of  the  lack 
of  quantitative  evidence. 

4.  Chapter  V.  A  Cost-Effectiveness  Assessment 

It  is  often  tacitly  accepted  that  automation  of  a  particular  task  has  inherent 
benefits  that  always  result  in  improved  combat  effectiveness.  Is  this  the  case  with 
MTACCS?  To  what  degree  will  automation  of  the  command  and  control  tasks  bring 
about  an  improvement  in  combat  effectiveness?  The  combat  effectiveness  assessment  in 
Chapter  V  will  address  these  questions.  In  addition,  the  cost  of  MTACCS  must  be  related 
to  its  ability  to  increase  effectiveness.  Some  investigation  must  be  made  to  determine  if 
spending  funds  on  MTACCS  is  an  optimal  use  of  resources. 

5.  Chapter  VI.  Combat  Development  Assessment 

Combat  Development  is  a  process  used  to  determine  the  course  of  the  Marine 
Corps  in  the  years  ahead.  Combat  Development  affects  doctrine,  training,  force  structure, 
and  equipment.  The  MTACCS  system  is  a  result  of  Combat  Development  practices. 
Chapter  VI  provides  an  overview  of  Combat  Development  and  assesses  its  likely  impact 
on  MTACCS. 


6.      Chapter  VII.   MTACCS  Interoperability  Assessment 

The  fifth  critical  area  concerns  interoperability.  In  October  of  1988,  the  Naval 
Research  Advisory  Committee  (NRAC)  released  a  report  on  the  intra/interoperability  of 
Marine  Corps  command  and  control  systems.  The  report  cited  several  interoperability 
concerns  with  MTACCS  at  that  time  and  proposed  several  recommendations  to  improve 
the  interoperability  posture  of  the  Marine  Corps.  An  obvious  question  then  is  "have  the 
recommendations  been  given  consideration"?  Chapter  VII  will  provide  an  assessment  of 
the  interoperability  efforts  of  MTACCS  and  the  levels  of  interoperability  expected  to  be 
achieved. 

C.      BACKGROUND  AND  HISTORY  OF  MTACCS 
1.      Background 

a.      The  Need  for  an  Automated  Command  and  Control  System 

The  National  Security  Act  of  1947  requires  that  the  Marine  Corps  provide 
rapidly  deployable  amphibious  forces  for  contingency  missions  in  support  of  the  national 
strategy.  A  key  statutory  mission  of  the  Marine  Corps  is  to  provide  Marine  Air  Ground 
Task  Forces  (MAGTF)  of  combined  arms,  together  with  supporting  air  components,  for 
service  with  the  fleet  in  the  seizure  or  defense  of  advanced  naval  bases  and  for  the 
conduct  of  such  land  operations  as  may  be  essential  to  the  prosecution  of  a  naval 
campaign.  The  coordination  of  such  a  large  number  of  forces  and  equipment  deployed 
over  a  wide  geographic  area  demonstrates  the  requirement  for  an  automated  command  and 
control  system  to  effectively  manage  the  assets  available.  [Ref.  2:p  3-1] 


In  order  to  accomplish  assigned  missions,  Marines  are  deployed  in  various 
states  of  readiness  around  the  globe.  In  some  cases,  Marines  and  their  equipment  are 
prepositioned  in  strategic  locations,  in  the  vicinity  of  trouble  areas.  When  Marines  must 
be  deployed,  they  must  go  through  various  phases  and  locations  in  order  to  ship  their 
resources  to  the  area  of  conflict.  This  requires  an  extensive  amount  of  logistical  and 
administrative  processing,  and  validates  the  requirement  for  automation.  [Ref.  2:p  3-1] 

Marines  train  on  a  daily  basis  for  the  conduct  of  war.  This  training  and 
the  keeping  of  personnel  records  requires  a  large  amount  of  time  and  effort  spent,  not  on 
training,  but  on  processing.  An  automated  system  of  personnel  and  training  record 
keeping  could  significantly  raise  the  amount  of  time  spent  on  training  and  increase  record 
accuracy.  [Ref.  2:p  3-2] 

An  automated  command  and  control  system  that  would  be  used  in  peace 
as  well  as  combat  would  facilitate  the  prosecution  of  battle  and  make  more  effective  use 
of  the  available  resources.  [Ref.  2:p  3-2] 

b.      The  Purpose  of  MTACCS 

The  MTACCS  concept  is  the  implementation  of  separate,  automation 
assisted  Marine  Air  Ground  Task  Force  (MAGTF)  command  and  control  systems  which 
support  tactical  operations.  MTACCS  is  to  enhance  the  commander's  decision  making 
capability  and  provide  the  tools  necessary  for  effective  and  efficient  command  and 
control.  MTACCS  is  to  support  maneuver  warfare,  focus  on  the  operational  level  of  war, 
support  MAGTF  internal  functional  requirements,  and  focus  on  the  MAGTF  area  of 
influence.  [Ref.  l:pp  1,4] 


c.      Concept  and  Characteristics 

The  objective  of  the  MTACCS  concept  is  to  provide  MAGTF 
commanders  with  an  integrated  set  of  systems  which  can  receive,  process,  display,  store, 
and  distribute  essential  information.  Figure  1  portrays  the  MTACCS  concept  as  it  is 
currently  envisioned.   The  subsystems  shown  will  be  defined  and  explained  in  detail  in 
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Figure  1:  Marine  Tactical  Command  and  Control  System  [Source:  MCCDC] 


Chapter  III.  MTACCS  is  an  engineering  effort  to  manage  the  integration  of  developed 
and  developing  automated  systems  to  support  tactical  operations.  MTACCS  will  provide 
commanders  with  a  semi-automated,  secure,  versatile,  rugged,  and  integrated  system  of 
tools  to  assist  them  in  effective  command  and  control.  It  consists  of  functionally  oriented 
systems  using  a  common  design  philosophy,  equipment,  operational  procedures,  data 
bases,  and  where  appropriate,  integration  with  other  systems  external  and  internal  to  the 
Marine  Corps.  MTACCS  is  based  upon  reliable  digital  communications  to  enhance 
planning,  direction,  coordination,  and  control  of  Marine  forces.  MTACCS  will  eventually 
provide  the  commander  with  one  system  to  support  both  tactical  and  non-tactical 
functions  while  providing  fused  and  correlated  information.  [Ref.  l:p  6] 

2.      History 

The  MTACCS  Master  Plan  of  1979  was  the  source  for  much  of  the  history 
contained  in  this  section.  Figure  2  shows  the  evolution  of  the  MTACCS  component 
systems  from  1969  to  the  present.1 

The  MTACCS  concept  first  started  in  1964,  when  the  Commandant  of  the 
Marine  Corps  (CMC)  tasked  the  Coordinator,  Marine  Corps  Landing  Force  Development 
Activities  2  to  act  as  the  contracting  technical  representative  for  the  conduct  of  Marine 


1  In  the  figure,  boxes  with  heavy  borders  denote  systems  that  have  been  fielded.  A 
detailed  description  of  these  systems  is  contained  in  Chapter  in. 

2  The  Marine  Corps  Landing  Force  Development  Activities  was  redesignated  Marine 
Corps  Development  and  Education  Command  (MCDEC).  MCDEC  was  later  reorganized 
into  the  Marine  Corps  Research,  Development,  and  Acquisition  Command  (MCRDAC) 
and  the  Marine  Corps  Combat  Development  Command  (MCCDC). 
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Figure  2:  MTACCS  Evolution  and  Mutations  [Source:  MCCDC] 

tactical  command  and  control  studies  by  Informatics,  Inc.  and  the  Stanford  Research 
Institute.  A  further  task  was  to  recommend  provisions  to  ensure  compatibility  with  other 
service  and  international  service  systems  to  be  operational  when  MTACCS  was  fielded. 
The  Informatics,  Inc.  study  developed  a  technical  system  concept  and  an  implementation 
concept.   The  technical  system  concept  had  five  functional  areas  that  included: 


1.  Tactical  Combat  Operations  (TCO) 

2.  Tactical  Air  Operations  (TAO) 


3.  Marine  Integrated  Fire  and  Air  Support  System  (MIFASS) 

4.  Marine  Integrated  Personnel  and  Logistics  (MIPLOG) 

5.  Communications  (Comm) 

Informatics  proposed  the  establishment  of  a  test  bed  consisting  primarily  of  off  the  shelf 
items  and  currently  available  test  equipment.  The  Stanford  Research  Institute  defined  and 
quantified  the  tactical  command  and  control  requirements. 

On  16  February,  1969,  the  Naval  Electronic  Systems  Command  (NAVELEX)3 
was  designated  the  Principle  Development  Activity  (PDA).  In  June  of  1969,  the  billet 
of  MTACCS  project  coordinator  was  established  in  the  office  of  the  Director, 
Management  Analysis  Group.  The  mission  of  this  MTACCS  coordinator  was  to  monitor 
and  coordinate  the  entire  MTACCS  project  through  its  development  and  system 
integration.  In  August  of  1969,  the  Marine  Corps  Development  Center  was  tasked  to 
provide  prototype  definition,  systems  effectiveness  analysis,  and  subsequent  operational 
system  development. 

By  August  1972,  the  test  bed  at  Camp  Pendleton,  California  had  been 
completed  and  full  scale  evaluation  of  MIFASS  had  started.  MIPLOG  had  evolved  into 
two  systems,  the  Marine  Integrated  Personnel  System  (MIPS)  and  the  Marine  Integrated 
Logistics  System  (MILOGS).  In  1973,  the  TAO  was  redesignated  Marine  Air  Command 
and  Control  System  -  85  (MACCS-85).  The  Position  Location  Reporting  System  (PLRS), 
Tactical  Warfare  Analysis  and  Evaluation  System  (TWAES)  and  Tactical  Exercise 


NAVELEX  later  became  Space  and  Naval  Warfare  Systems  Command  (SPAWAR). 


Simulator  and  Evaluator  (TESE)  were  added  to  the  concept,  bringing  the  total  number  of 
systems  to  ten. 

In  October  of  1973,  responsibility  for  the  coordination  of  MTACCS  was 
transferred  to  the  development  branch  of  the  Research,  Development,  and  Studies  Division 
at  HQMC.  Less  than  two  years  later,  a  HQMC  command  and  control  systems 
coordinating  committee  was  established  with  membership  from  each  principle  HQMC 
office  concerned  with  the  development  and  support  of  MTACCS  and  from  MCDEC. 

The  first  MTACCS  Master  Plan  was  published  in  1976.  The  issuing  directive 
required  that  the  plan  be  updated  annually.  About  this  time,  the  requirement  for  a 
dedicated  MTACCS  communications  system  was  deleted,  and  TWAES  and  TESE  were 
combined  into  Tactical  Warfare  Simulation,  Evaluation,  and  Analysis  System  (TWSEAS). 

The  Technical  Interface  Concepts  were  published  in  1978  and  provided  basic 
inter/intraoperability  criterion.  [Ref.  3:  pp  1-5  -  1-9] 

In  September  1979,  the  MIFASS  contract  was  awarded  to  Norden  Systems 
Incorporated  for  a  projected  cost  of  $44  million  and  a  delivery  date  of  October  1982.  The 
following  year,  new  Marine  Corps  standards  were  published  in  the  Tactical  Interface 
Design  Plan  (TIDP).  This  resulted  in  a  requirement  for  a  Unit  Level  Message  Switch 
(ULMS),  a  significant  increase  in  software  documentation,  and  a  $14  million  increase  in 
costs.  After  the  Assistant  Commandant  of  the  Marine  Corps  (ACMC)  was  notified  by 
SPA  WAR  that  Norden  would  have  a  problem  in  meeting  the  delivery  deadline,  the 
ACMC  decided  to  delete  four  requirements,  defer  eight  others,  and  delay  the  delivery  by 
twelve  months.   Major  General  D.  B.  Barker  and  a  panel  of  senior  officers  conducted  a 
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study  of  the  acquisition  of  MIFASS.  Their  results  described  a  number  of  problems  with 
the  acquisition  process,  with  the  Marine  Corps'  definition  of  requirements,  and  with  a 
lack  of  consensus  concerning  doctrinal  issues.  Development  continued  with  increasing 
costs  and  lengthening  delays  until  MIFASS  was  finally  terminated  in  May  1987  at  a  cost 
of  $236  million.4  [Ref.  4,5]  MACCS-85  was  renamed  the  Tactical  Air  Operations 
Module  (TAOM)  and  is  currently  being  fielded.  The  PLRS  system  was  also  fielded.  Due 
to  the  cancellation  of  MIFASS,  the  cornerstone  of  the  original  MTACCS  concept,  the 
remaining  systems  (TCO,  TWSEAS,  etc.)  continued  development  but  only  nominal 
integration  of  these  systems  was  attempted.  MTACCS  was  revitalized  in  1989  and  an 
Operational  Concept  document  was  published  in  April  of  1990.  [Ref.  1] 


4  This  amount  is  based  on  a  MIFASS  chronology  written  by  the  last  MIFASS  ASPO. 
Several  other  figures  have  been  published.  In  1989,  the  GAO  wrote  "About  $150 
Million"  was  spent  on  MIFASS.  [Ref.  5:p  23]   The   great  disparity  cannot  be  resolved. 
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n.   THE  TERMINATION  OF  MIFASS 

A.      INTRODUCTION 

1.  Purpose  of  this  Chapter 

The  purpose  of  this  chapter  is  to  investigate  the  circumstances  that  led  to  the 
recent  termination  of  a  Marine  Corps  attempt  to  procure  a  command  and  control  system. 
That  system  was  called  the  Marine  Integrated  Fire  and  Air  Support  System  (MIFASS). 
After  nearly  twenty  years  of  development  and  an  expenditure  of  more  than  $200  million, 
the  program  was  terminated  in  1987  while  still  in  the  full  scale  development  phase. 

The  remainder  of  this  introductory  section  describes  the  MIFASS  system, 
provides  a  brief  history  of  MIFASS,  and  introduces  the  key  players  involved  in  the 
procurement  of  MIFASS.  Section  B  provides  several  viewpoints  and  opinions  on  the 
possible  causes  of  the  termination.  Section  C  attempts  to  sort  through  all  of  the  varied 
opinions  and  arrive  at  a  determination  of  the  most  significant  factors  that  contributed  to 
the  cancellation  of  the  program. 

2.  A  Description  of  the  MIFASS  System 

The  Marine  Integrated  Fire  and  Air  Support  System  (MIFASS)  was  a 
subsystem  of  the  Marine  Tactical  Command  and  Control  System  (MTACCS).  It  was 
designed  to  operate  directly  or  indirectly  with  the  systems  included  in  the  MTACCS 
concept  and  with  other  services  and  NATO  systems  as  well.  [Ref.  3]  MIFASS  was  a 
combination  of  equipment,  personnel,  and  associated  procedures.  They  were  to  provide 
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a  means  for  exercising  command  and  control  (C2)  of  fire  and  air  support  assets  within  a 
Marine  Air  Ground  Task  Force  (MAGTF).  [Ref.  6:p  D-3]  MIFASS  was  to  provide 
support  in  the  immediate  attack  of  targets  of  opportunity  and  to  give  automated  assistance 
in  fire  planning,  target  intelligence,  counter  fire  operations,  nuclear  and  biological  target 
analysis,  forward  area  air  defense,  mission  activity  reporting,  and  low  altitude  airspace 
management. 

MIFASS  centers  were  to  be  located  at  various  levels  within  the  MAGTF  acting 
as  the  primary  agency  for  the  control  of  all  supporting  arms.  Suites  of  equipment  were 
to  be  constructed  around  a  set  of  software  modules  to  enable  a  complete  set  of  system 
capabilities.  [Ref.  6:p  1-5]  MIFASS  software  was  originally  designed  to  provide 
automation  to  assist  the  MAGTF  in  operating  within  a  new  tactical  doctrine  implemented 
by  a  system  of  Fire  and  Air  Support  Centers  (FASC).  The  basic  tenet  of  fire  support 
prior  to  MIFASS  and  the  FASC  concept  had  been  decentralization  (Figure  3).  The  FASC 
concept  was  to  reorganize  and  centralize  the  C2  of  fire  support  (Figure  4).  The  FASC's 
were  to  assume  the  functions  of  both  the  Direct  Air  Support  Center  (DASC)  and  the  Fire 
Support  Coordination  Center  (FSCC),  and  selected  roles  of  supporting  artillery  units  and 
naval  gunfire  ships  as  well.  [Ref.  6,  7:pII-2]  The  new  FASC  doctrine  would  employ 
MIFASS  equipment  to  semi-automate  both  fire  support  coordination  and  air  support 
coordination  within  one  center.  The  established  decentralized  doctrine  employed  FSCCs 
to  provide  manual  coordination  of  fire  support  and  a  DASC  to  provide  manual 
coordination  of  air  support.  The  change  to  a  more  centralized  doctrine  and  the  FASC 
concept  was  never  officially  endorsed  or  approved,  but  was  supported  by  many  key 
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decision  makers  in  the  Marine  Corps.  [Ref.  7:p  D-3]  This  would  later  prove  to  be 
a  key  weakness  of  the  MIFASS  program.  Although  MIFASS  was  initially  intended  to 
support  the  more  centralized  fire  support  doctrine,  the  Marine  Corps  had  great  difficulty 
in  its  efforts  to  achieve  a  consensus  acceptance  of  centralization.  In  the  end,  that 
consensus  was  never  achieved.  By  1983,  the  centralized  doctrine  and  the  FASC  concept 
appear  to  have  been  abandoned.  The  problems  that  resulted  from  this  lack  of  consensus 
are  discussed  in  detail  in  Section  B  of  this  chapter. 

MIFASS  equipment  consisted  of  real-time  display  and  information  processing 
equipment  capable  of  displaying  friendly  unit  and  target  locations  and  of  processing 
requests  for  fire  and  air  support.  This  equipment  was  to  be  located  in  the  FASCs  and 
artillery  Fire  Direction  Centers  (FDC's).  Firing  units  would  have  small,  hand  held,  off- 
line calculators  to  automate  fire  direction  computations.  Supporting  arms  observers  would 
have  been  furnished  Digital  Communications  Terminals  (DCT)  along  with  their 
manpacked  radios  in  order  to  enhance  communications  with  the  FASC.  The  MIFASS 
concept  envisioned  supporting  arms  requests  being  routed  simultaneously  to  the  FASC 
in  the  area  to  be  supported  and  the  FASC  who  would  control  the  unit  providing  the 
support.  The  senior  FASC  would  clear  the  request  by  verifying  friendly  unit  safety  and 
conformance  to  other  coordination,  control,  and  limiting  measures.  Potential  conflicts 
between  ground  and  air  support  were  to  be  coordinated  laterally  between  FASCs. 

MIFASS  was  a  very  far  sighted  concept.  The  development  of  this  program 
was  an  extreme  challenge  to  the  Marine  Corps.    It  would  take  nearly  a  quarter  of  a 
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century  for  the  program  to  run  its  course.  The  next  section  provides  a  brief  history  of  this 
ill-fated  project. 

3.      MIFASS  Chronology 

The  following  is  an  abbreviated  summary  of  more  than  twenty  years  of 
MIFASS  history. 


1964  -  The  Marine  Corps  hired  the  Stanford  Research  Institute  and  Informatics,  Inc. 
to  conduct  Marine  Tactical  Command  and  Control  studies.  The  results  identified 
5  functional  areas  to  be  developed,  one  of  which  was  MIFASS. 

July  1967  -  The  first  formal  requirements  documents  describing  MIFASS  were 
published. 

February  1969  -  Naval  Electronic  Systems  Command  (NAVELEX,  later  it  became 
Space  and  Naval  Warfare  Systems  Command  (SPAWAR))  was  designated  the 
Principle  Development  Activity  for  MTACCS  (including  MIFASS)  by  the  Chief  of 
Naval  Material  at  the  request  of  the  Commandant  of  the  Marine  Corps. 

June  1969  -  The  Marine  Corps  established  a  charter  for  MTACCS  which  delineated 
the  functions  of  the  Headquarters  Marine  Corps  (HQMC)  staff  and  established  a 
MTACCS  Project  Coordinator. 

August  1969  -  MCDEC  was  designated  as  the  field  agency  test  bed  activity  for 
MTACCS  and  was  tasked  to  provide  prototype  definition,  systems  effectiveness 
analysis,  and  subsequent  operational  development. 

1972  -  An  MTACCS  test  bed  was  established  at  Marine  Corps  Tactical  Systems 
Support  Activity  (MCTSSA),  Camp  Pendleton,  Ca.  The  MIFASS  concept  was  the 
first  to  be  tested  and  was  found  to  be  a  valid  requirement  for  continued 
development. 

December  1974  -  In  response  to  the  test  bed  results,  a  MIFASS  Required 
Operational  Capabilities  (ROC)  was  staffed,  starting  the  formal  acquisi- 
tion/development of  the  system.   The  ROC  was  approved  and  published  in  1975. 

March  1976  -  A  review  of  MIFASS  design  alternatives  was  held  and  it  was  decided 
to  develop  MIFASS  with  both  the  current  organization  and  doctrine  and  with  the 
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new  organization  (combine  the  DASC  and  FSCC  into  a  FASC).  This  was  not  to 
be  construed  as  approval  of  any  organizational  or  doctrinal  changes. 

February  1977  -  Approval  was  granted  for  full  scale  development  of  a  MIFASS 
Engineering  Development  Model  (EDM).  The  question  of  which  organization  and 
doctrine  to  use  remained  unresolved  and  development  was  directed  to  proceed  with 
both. 

September  1979  -  A  cost  plus  incentive  fee  contract  was  awarded  to  Norden 
Systems  Incorporated  (United  Technologies  Corporation).  Cost  projections  were 
$44  million  and  a  delivery  date  of  October  1982. 

July  1980  -  Assistant  Commandant  of  the  Marine  Corps  (ACMC)  Committee  met 
and  established  a  requirement  for  a  Unit  Level  Message  Switch  (ULMS)  and 
increased  software  documentation  of  MIFASS  as  a  result  of  the  new  Marine  Corps 
wide  standards  promulgated  in  the  Tactical  Interface  Design  Plan  (TIDP).  Projected 
costs  increased  to  $58  million  and  the  delivery  date  slid  to  April  1983.  At  this 
time,  Norden  was  directed  to  change  all  subcontracts  to  fixed  price  contracts. 

December  1982  -  ACMC  Committee  was  notified  by  the  PDA  that  Norden  would 
have  problems  in  meeting  the  April  1983  delivery  deadline  due  to  problems  in 
implementing  the  TIDP.  The  committee  decided  to  delete  four  requirements  and 
defer  eight  others.  A  developmental  delay  of  12  months  was  authorized.  Major 
General  D.  B.  Barker,  DOS  for  Training,  chaired  a  study  group  formed  at  this  time 
to  review  MIFASS  requirements.  Projected  costs  were  $158.14  million  with  EDM 
delivery  in  April  1984. 

May  1982  -  Chief  of  Staffs  Committee  reviewed  the  Barker  study  and  decided  to 
continue  development  of  the  EDM  using  both  doctrines  and  organizations. 

July  -  December  1982  -  The  projected  costs  increased  $14  million  due  to  interface 
software  for  the  Digital  Communications  Terminal  (DCT),  development  of  digital 
error  correction,  and  to  evaluate  the  feasibility  of  integrating  the  Tactical  Combat 
Operations  (TCO)  System  (another  element  of  MTACCS). 

June  1983  -  The  ACMC  Committee  convened  to  review  two  ADMs: 

1 .  Approval  for  a  modification  allowing  a  six  month  extension  for  the  EDM 
delivery  date. 

2.  The  requirement  for  ACMC  approval  prior  to  expenditure  of  more 

funds  on  MIFASS. 
The  decision  was  also  made  to  conduct  Operational  Testing  II  (OT-II)  using  only 
decentralized  doctrine  and  organization.    Work  around  for  software  changes  was 
estimated  at  $3  Million. 
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July  1984  -  ACMC  Committee  granted  an  extension  of  five  months  for  Engineering 
Development  Model  (EDM)  delivery  and  approved  a  50/50  cost  sharing  plan, 
proposed  by  Norden,  of  the  $13  million  for  continued  development.  SPAWAR,  the 
Principle  Development  Activity  (PDA),  was  directed  to  negotiate  a  cap  on  the 
MIFASS  development  costs  with  the  contractor.  Projected  costs  are  $135  million 
with  a  delivery  date  of  March  1985. 

May  1985  -  The  ACMC  Committee  met  to  modify  MIFASS  acquisition  strategy. 
It  was  decided  that  a  modified  software  package  be  completed  with  full  capability 
included  either  in  the  MIFASS  production  model  or  in  the  Preplanned  Product 
Improvement  Model  (P3I).  It  was  decided  that  the  delivery  date  of  the  system  be 
extended  thirteen  months  and  an  additional  $7  million  be  expended.  Projected  costs 
were  $210.88  million  with  a  delivery  date  of  April  1986. 

October  1985  -  During  a  status  brief  to  the  ACMC  Committee,  SPAWAR  was 
directed  to: 

1.  Develop  an  acquisition  plan  based  on  competition  for  the  production 
contract. 

2.  Develop  a  finite  list  of  required  modifications. 

3.  Complete  a  detailed  R&D  plan  for  MIFASS  by  task  and  year. 

4.  Provide  pros  and  cons  of  MIFASS  as  perceived  by  past  and  present  First  Marine 
Amphibious  Force  Test  Directors. 

March  1986  -  The  ACMC  Committee  received  a  proposed  improved  acquisition 
plan  from  the  PDA,  and  the  finite  list  of  required  modifications  which  totaled  $19.8 
million. 

May  1987  -  the  ACMC  recommended  to  the  CMC  the  termination  of  MIFASS. 
Total  funds  spent  on  MIFASS  exceeded  $236  million.  [Ref.  4] 


4.      Key  Players  and  Their  Responsibilities 

No  single  individual  was  ever  designated  as  the  program  manager  for  MIFASS. 
Program  management  was  primarily  accomplished  through  an  Acquisition  Coordinating 
Group.  The  Acquisition  Coordinating  Group  was  principally  a  decentralized  assembly  of 
personnel  from  HQMC  staff  sections  and  from  the  Marine  Corps  Development  Center. 
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[Ref.  8]      The   acquisition   organization   used   for  the   development   of  MIFASS   is 
shown  in  Figure  5. 

a.      The  Acquisition  Coordinating  Group  (ACG) 

This  coordinating  group  consisted  of  action  officer  representatives  from 
the  Marine  Corps  Development  Center,  the  HQMC  Research,  Development  and  Studies 
staff  section,  the  Installations  and  Logistics  staff  section,  and  the  Command,  Control, 
Communications,  and  Computer  Systems  (C4  Systems)  staff  section.  The  functions  of  the 
group  included: 

1.  Write  and  execute  the  Acquisition  Strategy  Plan  (ASP)  and  the  Material 
Acquisition  Process  (MAP). 

2.  Exchange  information  and  coordinate  actions  of  its  members. 

3.  Document  program  history. 

4.  Recommend  program  management  actions  to  the  Acquisition  Program  Sponsor 
(APS)  who  was  the  Director,  Command,  Control,  Communications,  and  Computer 
Systems.  [Ref.  8:p  16] 

(1)  Acquisition  Sponsor  Project  Officer  (ASPO).  The  leading  member 
of  the  group  was  the  Acquisition  Sponsor  Project  Officer  (ASPO)  who  was  responsible 
for  MIFASS  systems  acquisition.  The  ASPO  was  a  representative  from  the  program 
sponsor,  the  C4  Systems  branch  at  HQMC.   His  primary  duties  included: 

1 .  Coordinating  staff  action  for  the  program  sponsor. 

2.  Ensuring  the  accuracy  of  the  ROC  and  the  Life  Cycle  Cost  Forecast  (LCCF). 
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Figure  5:  MIFASS  Acquisition  Organization  Diagram  [Source:  Authors] 
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3.  Developing  the  ASP,  MAP,  and  the  Manpower  Training  Plan  (MTP). 

4.  Preparing  the  program  objective  memorandum  (POM). 

5.  Providing    program    action    recommendations    to    the    sponsor    for    approval. 
[Ref.  8:p  17] 

(2)  Development  Project  Officer  (DPO).  The  second  key  member  was 
the  Development  Project  Officer  (DPO)  who  was  responsible  for  the  day  to  day 
management  of  the  MIFASS  development  program.  The  DPO  was  a  representative  from 
the  Development  Center.    His  principle  responsibilities  were: 

1.  To  act  as  the  single  Marine  Corps  point  of  contact  for  tasking  the  Principle 
Development  Activity  (PDA). 

2.  To  prepare  RDT&E  work  directives. 

3.  To  prepare  Statements  of  Work. 

4.  To  provide  program  review  briefings.  [Ref.  8:p  17] 

(3)  Acquisition  Project  Officer  (APO).  The  Acquisition  Project  Officer 
(APO)  was  the  third  key  member.  The  APO  was  a  representative  from  the  Installations 
and  Logistics  staff  section  at  HQMC.  His  responsibility  was  for  the  management  of  the 
logistical,  technical,  and  engineering  aspects  of  production,  fielding,  operations,  support, 
and  retirement.   His  major  responsibilities  included: 

1.  Developing  the  Integrated  Logistics  Support  Plan  (ILSP). 

2.  Assisting  in  the  development  of  LCCF  data  to  support  program  initiation  and 
documentation. 
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3.  Ensuring    reliability,     maintainability,     supportability,     and     other    logistical 
requirements  are  included  in  the  system  design. 

4.  Assisting  the  ASPO  in  the  programming  of  funds.  [Ref.  8:p  16] 


(4)  Development  Coordinator  (DC).  The  Development  Coordinator 
(DC)  was  the  final  key  member  of  the  Acquisition  Coordinating  Group.  The  DC  was  a 
representative  from  the  Research,  Development,  and  Studies  staff  section  at  HQMC.  His 
responsibility  was  to  coordinate  the  MIFASS  acquisition  program.  His  major  duties  were: 

1.  To  maintain  the  master  project  file. 

2.  To  assist  in  the  preparation  of  the  ASP  and  the  MAP,  and  the  programming  of 
funds.  [Ref.  8:p  16] 

b.      HQMC  Staff 

The  Commandant  of  the  Marine  Corps  (CMC)  was  authorized  to  make 
the  final  Acquisition  Category  He  (ACAT  lie)  decision  of  continuing  or  canceling 
MIFASS.  The  Assistant  Commandant  of  the  Marine  Corps  (ACMC)  was  designated  the 
Acquisition  Executive  (AE).  As  AE  he  was  required  to  monitor  and  control  the 
acquisition  development  of  MIFASS  and  report  to  the  CMC.  The  AE  had  decision 
authority  for  funding  and  schedule  changes  for  MIFASS  acquisition.  The  ACMC  chaired 
an  ad  hoc  group  of  selected  General  officers  called  the  ACMC  Committee.  The  purpose 
of  this  committee  was  to  act  as  a  program  review  body,  but  not  as  a  milestone  review. 
As  problems  with  MIFASS  surfaced  at  an  increasing  rate,  the  Committee  assumed  many 
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of  the  responsibilities  previously  held  by  the  Acquisition  Program  Sponsor  (Director, 
Command,  Control,  Communications,  and  Computer  Systems  Division).  [Ref.  8:p  16] 

c.      Deputy  Chief  of  Staff  for  Research,  Development,  and  Studies 

The  office  of  the  Deputy  Chief  of  Staff  for  Research,  Development,  and  Studies 
was  responsible  for  acquisition  matters  for  ground  combat  systems  from  program 
initiation  until  the  systems  were  ready  for  production.  [Ref.  9:p  54] 

The  Deputy  Chief  of  Staff  for  Research,  Development,  and  Studies 

(DC/S  RD&S)  acted  as  the  Program  Executive  Officer  (PEO)5  for  MIFASS  development 

up  to  Milestone  III.   His  primary  responsibilities  included: 


1.  Providing  the  Development  Coordinator  (DC)  to  the  Acquisition  Coordinating 
Group. 

2.  Coordinating  the  review  and  approval  of  all  MIFASS  requirement  documents. 

3.  Ensuring  a  link  between  Mission  Needs,  Research  Development,  Test  and 
Evaluation  (RDT&E). 

4.  Preparing  Acquisition  Decision  Memorandums.  [Ref.  8:p  18] 


d.      Director,  Command,  Control,  Communications,  and  Computer  Systems 

The  Acquisition  Program  Sponsor  (APS)  was  the  Director,  Command, 
Control,  Communications,  and  Computer  Systems  Division  (DirC4SysDiv).  His 
responsibilities  included: 


1.     Providing  the  MIFASS  Acquisition  Sponsor  Project  Officer  (ASPO)  to  the 
Acquisition  Coordinating  Group. 


5  The  Program  Executive  Officer  (PEO)  is  generally  described  as  a  middle  manager 
responsible  for  several  separate  programs. 
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2.  Interoperability,  intraoperability,  and  compatibility  interface  of  MIFASS  with  other 
Systems. 

3.  Reviewing  all  program  initiations  and  requirements  for  MIFASS. 

4.  Being  the  principle  point  of  contact  for  management  and  planning  guidance. 

5.  Assessing  the  capability,  suitability  and  cost  of  the  program. 

6.  Initiating  the  mission  area  analysis  for  MIFASS   in  determining  operational 
requirements.  [Ref.  8:p  19] 

e.      The  Deputy  Chief  of  Staff  for  Installations  and  Logistics 

The  office  of  the  Deputy  Chief  of  Staff  for  Installations  and  Logistics  became  the 
acquisition  focal  point  during  the  production  and  development  stages  and  throughout 
the  remainder  of  the  systems'  life  cycle.  [Ref.  9:p  54] 

The  Deputy  Chief  of  Staff  for  Installations  and  Logistics  (DC/S  I&L) 

would  have  assumed  the  duties  as  the  PEO  had  MIFASS  reached  the  production  and 

deployment  phase.   His  major  responsibilities  included: 


1.  Providing  the  Acquisition  Project  Officer  (APO)  who  is  a  member  of  the 
Acquisition  Coordinating  Group. 

2.  Planning  and  coordinating  ILSPs  up  to  Milestone  III. 

3.  Ensuring  reliability,  availability,  maintainability,  and  quality  assurance  were  given 
due  consideration  during  MIFASS  development.  [Ref.  8:p  18] 


/.       The  Marine  Corps  Development  Center 

The  Director  of  the  Marine  Corps  Development  Center  (DirDevCtr)  was 
subordinate  to  the  Commanding  General  of  the  Marine  Corps  Development  and  Education 
Command  (MCDEC).  Although  the  Development  Center  was  not  directly  subordinate  to 
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the  DC/S  RD&S,  there  was  an  obvious  need  for  close  coordination  between  the  two. 
The  RD&S  staff  section  was  responsible  for  development  policy  within  the  Marine  Corps. 
The  Development  Center  implemented  that  policy.  The  major  responsibilities  of  the 
director  included: 

1.  Providing  the  MIFASS  Development  Project  Officer  (DPO)  to  the  ACG. 

2.  Managing  the  Marine  Corps  Long  Range  Studies  Program  that  generated  a  need 
for  MIFASS,  and  submitting  requirement  documents  to  DC/S  RD&S  for  HQMC 
staffing. 

3.  Conducting  Mission  Area  Analysis  as  requested. 

4.  Acting  as  the  single  agency  responsible  for  the  management  of  work  performed 
by  the  PDA  and  associated  contractors.  [Ref.  8:p  20] 

g.      The  Principle  Development  Activity  (PDA) 

SPAWAR  was  the  PDA  for  MIFASS  and  it's  mission  was  to  support  the 
Marine  Corps  by  providing  for  the  design,  development,  integration,  test  and  evaluation, 
and  procurement  of  MIFASS  to  satisfy  operational  requirements.  SPAWAR  managers 
received  guidance  and  direction  from  CMC,  but  still  reported  to  the  Commander  of 
SPAWAR. 

B.      SEVERAL  VIEWPOINTS  ON  THE  TERMINATION  OF  MIFASS 

1.      What  Went  Wrong? 

Many  opinions  on  this  subject  have  been  published  in  the  three  years  since  the 
announcement  of  the  termination  and  many  people  have  addressed  the  question:  "What 
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went  wrong?".  Not  surprisingly,  these  numerous  perspectives  have  offered  varied,  and 
sometimes  conflicting,  answers  to  that  question.  The  termination  of  the  MIFASS  program 
can  undoubtably  be  traced  to  many  interrelated  factors.  In  this  section,  the  viewpoints 
and  opinions  of  several  key  people,  agencies,  and  groups  will  be  examined. 

2.      The  Barker  Working  Group  Study  of  MIFASS,  1982 

By  late  1981,  several  MIFASS  program  perturbations  had  led  to  significant 
cost  increases  and  schedule  delays.  Many  key  decision  makers  within  the  Marine  Corps 
were  developing  serious  doubts  that  the  MIFASS  program  was  still  viable.  The  Assistant 
Commandant  of  the  Marine  Corps  (ACMC)  directed  that  a  working  group  be  established 
to  revalidate  the  MIFASS  requirement,  determine  cost  effectiveness,  and  develop 
recommendations  concerning  the  continuation  of  the  MIFASS  program. 
[Ref.  10:pp  2-4]  This  group  was  chaired  by  Major  General  D.  B.  Barker,  USMC, 
and  is  referred  to  throughout  this  thesis  as  the  Barker  Working  Group. 

By  April  of  1982,  the  working  group  had  completed  its  evaluation.  The  report 

was  very  critical  of  the  excessive  size  and  weight  of  MIFASS.   It  stated: 

Easily  the  most  significant  problem  associated  with  MIFASS  is  its  impact  on  the 
mobility  and  survivability  of  maneuver  command  posts  at  every  level.  Although 
the  Marine  Tactical  Command  and  Control  System  (MTACCS)  Master  Plan  states 
that  equipment  size  and  weight  must  not  exceed  the  transportation  capability 
available  to  the  using  unit... there  is  little  evidence  of  adherence  to  that  guidance. 
[Ref.  ll:p  22] 

Significant  among  the  group's  conclusions  was  its  declaration  that  "the  1979 

MIFASS  Required  Operational  Capability  (ROC)  was  invalid"  [Ref.  1  l:p  38].  The  group 
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found  it  necessary  to  submit  its  own  ROC  as  a  recommended  replacement  for  the  1979 
ROC.   Other  key  observations  included: 


1 .  Despite  years  of  test  bed  development,  the  government  was  not  fully  prepared  to 
go  to  contract  in  1979  because  it  had  not  clearly  specified  the  functional  flow 
diagrams  which  were  to  form  the  basis  for  software  development. 

2.  The  contractor  underestimated  the  complexity  and  difficulty  of  MIFASS  software 
development. 

3.  The  Marine  Corps  organization  for  development  is  inadequate.  [Ref.  ll:p  27] 


Several  courses  of  action  were  studied  by  this  group.  Among  these  were  to 
continue  the  MIFASS  program  in  accordance  with  the  1979  ROC,  to  significantly  modify 
the  program,  or  to  terminate  MIFASS  and  look  elsewhere  for  a  command  and  control 
system.  Continuation  of  the  program  without  modification  was  flatly  rejected.  Major 
modifications  to  the  program  were  recommended  including  the  merger  of  MIFASS  with 
the  Tactical  Combat  Operations  (TCO)  program  and  deletion  of  the  FASC  concept. 
[Ref.  ll:p  41]  The  ACMC  committee  chose  not  to  implement  the  study's 
recommendations  because  they  required  major  changes,  and  the  belief  at  the  time  was  that 
MIFASS  was  only  six  months  away  from  operational  testing  [Ref.  8:p  37]. 

3.      The  General  Accounting  Office,  1983-1986 

During  the  period  of  1983  to  1986,  both  the  Congress  and  the  GAO  took  a 
specific  interest  in  the  development  of  battlefield  command  and  control  (C2)  systems. 
At  least  five  GAO  reports  reviewed  Army  and  Marine  Corps  fire  support  C2  systems 
during  these  years.  Generally,  there  was  heightened  interest  by  the  Services,  OSD,  GAO, 
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and  the  Congress  in  clarifying  the  need  to  have  both  battlefield  support  systems,  the 

Army's  Advanced  Field  Artillery  Tactical   Data  System   (AFATDS)  and   MIFASS. 

[Ref.  12:p    10]      Marine   Corps  justification   for   MIFASS   was   AFATDS'    inability 

to  integrate  combined  air/ground  operations  and  its  lack  of  a  real  time  coordination 

capability  with  aircraft. 

In  October  of  1983,  the  General  Accounting  Office  (GAO)  reviewed  both  the 

Army's  and  the  Marine  Corps'  efforts  to  automate  their  fire  support  command  and  control 

functions.   The  GAO  report  to  the  Secretary  of  Defense  stated: 

The  potential  for  common  fire  support  command  and  control  systems  in  the  Army 
and  the  Marine  Corps  has  not  been  exploited  in  spite  of  the  Department  of 
Defense's  (DOD's)  policies  promoting  standardized  systems  and  equipment. 
Although  the  missions  are  similar  and  the  fire  support  systems  need  to  communicate 
with  each  other,  each  service  is  developing  its  own  systems.  This  has  led  to 
possible  duplication  of  development  efforts  and  interoperability  problems. 
[Ref.  13:p  1] 

This  appears  to  be  the  first  alarm  being  sounded  that  standardization  is  being 

ignored  and  that  "possible  duplication"  exists.   The  GAO  position  was  critical: 

Mission  differences  exist,  and  while  these  differences  may  constrain  the  degree  of 
commonality,  they  do  not  preclude  it... [Ref.  13:p  4]  Neither  service  has  explained 
why  these  differences  require  systems  with  totally  unique  hardware  and  software. 
[Ref.  13:p  6] 

The  GAO  opinion  here  has  substantial  merit.  There  are  extensive  similarities 

in  the  fire  support  procedures  used  by  the  Army  and  the  Marine  Corps.    Marine  Corps 

artillerymen  are  trained  at  the  Army  Artillery  School  at  Fort  Sill,  Oklahoma.  Marines  use 
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several  Army  field  manuals  for  artillery  operations6.  Much  of  the  equipment  and 
weaponry  used  is  identical.  While  there  are  important,  critical  differences7,  the 
significant  degree  of  commonality  in  fire  support  procedures  should  not  be  overlooked. 
While  this  report  states  its  case  clearly  and  raises  good  questions,  little 
attention  appears  to  have  been  paid  to  it.  If  considerable  duplication  was  taking  place, 
it  would  seem  to  be  only  common  sense  that,  sooner  or  later,  one  of  the  programs  would 
become  indefensible  and  the  ax  would  fall.  Secretary  of  Defense  Mr.  Caspar  Weinberger, 
however,  did  relatively  little  during  his  tenure  to  constrain  the  requests  of  the  services. 
[Ref.  14:p  123]  Given  the  ever  increasing  defense  budgets  of  the  early  80's,  the 
duplication  was  fiscally  possible.  If  the  Army  and  the  Marine  Corps  wanted  to  go  their 
separate  ways,  the  barest  of  justifications  was  sufficient  to  gain  DOD  approval.  It  is 
doubtful  this  duplication  was  intentional.  Redundancy  is  often  the  chosen  method  of 
ensuring  survivability.  In  this  case,  however,  redundancy  may  simply  have  been 
tolerated. 

4.      The  Institute  for  Defense  Analyses  (IDA),  early  1987 

In  July  of  1986,  the  Under  Secretary  of  Defense  for  Research  and  Engineering 
requested  that  IDA  perform  an  independent  assessment  of  the  fire  support  command  and 


6  FM  6-20  "Combined  Arms  Operations",  FM  6-30  "The  Field  Artillery  Observer", 
FM  6-40  "Field  Artillery  Cannon  Gunnery",  and  FM  6-50  "The  Field  Artillery  Battery" 
are  just  a  few  examples. 

'  The  Marine  Corps  has  organic  fixed  wing  fire  support,  for  example,  and  plans  for 
extensive  employment  of  Naval  gunfire. 
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control  systems  being  developed  by  the  Army  and  the  Marine  Corps.  In  his  letter,  he 
emphasized  "Considerable  momentum  is  developing  to  combine  the  two  programs." 
[Ref.  15:p  1]  In  directing  the  IDA  study,  the  Secretary  of  Defense,  Mr. 
Weinberger,  stated  that  DOD  would  "ensure  maximum  cross-service  commonality  and 
interoperability  of  these  systems."  [Ref.  16:p  1]  Aside  from  any  problems  that 
either  program  may  have  been  having,  both  Congress  and  the  GAO  had,  by  this  time, 
long  been  questioning  why  the  Army  and  the  Marine  Corps  were  both  developing  separate 
systems  to  do  principally  the  same  tasks. 

By  early  1987,  the  IDA  report  had  been  completed.  The  intent  of  the  study 
was  to  provide  an  independent  assessment  of  the  potential  to  consolidate  the  MIFASS 
and  AFATDS  programs  [Ref.  12:p  7]  The  study  examined  the  feasibility  of  three  options: 

1.  Both  services  field  MIFASS. 

2.  Both  services  field  AFATDS. 

3.  Army  fields  AFATDS  and  the  Marine  Corps  fields  MIFASS. 

The  study  first  evaluated  the  ability  of  AFATDS  to  meet  the  needs  of  the 
Marine  Corps  without  modification.  The  general  finding  was  that,  without  modification, 
AFATDS  would  not  meet  the  requirements  of  the  Marine  Corps  as  then  stated.  It  further 
concluded  that  "Although  it  appears  that  AFATDS  could  be  adapted  to  Marine  Corps 
needs,  this  adaptability  needs  to  be  demonstrated"  [Ref.  12:p  66].  While  it  was 
understood  that  AFATDS  would  require  modification,  the  IDA  study  still  painted  a  poor 
picture  of  MIFASS  in  three  important  areas:  cost,  weight,  and  interoperability.  It  stated: 
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MIFASS  for  the  Army  would  weigh  between  two  and  five  times  as  much  as 
AFATDS...The  variation  in  weight  due  to  the  uncertainty  as  to  whether  the  Army 
would  populate  its  centers  with  one  string  of  equipment  or  two  strings  as  the 
Marine  Corps  has  planned.  [Ref.  12:p  44] 

Five  years  after  the  Barker  Working  Group,  MIFASS  was  once  again  declared 
to  be  too  heavy.  Also  of  major  note  is  their  finding  that  fielding  a  sufficiently  ruggedized 
version  of  AFATDS  to  the  Marine  Corps  would  cost 

$285  Million  to  $355  Million  less  than  fielding  MIFASS,  a  savings  of  65-80%. 
[Ref.  12:p  48]  Worse  yet,  fielding  MIFASS  to  the  Army  "could  quadruple  the  cost  of  the 
Army  program."  [Ref.  12:p  64]  From  an  interoperability  standpoint,  MIFASS  would 
have  little  commonality  with  any  of  the  other  MTACCS  Systems  [Ref.  12:p  E-20]  At 
the  present  time,  AFATDS  is  optimistically  expected  to  reach  full  scale  development  in 
1992.  [Ref.  5:p  13] 

The   IDA   report   concluded   that   the   Marine   Corps   should   conduct   an 

Adaptability  Evaluation  Program  (AEP)  to  validate  the  concept  of  adapting  AFATDS  to 

the  needs  of  the  Marine  Corps.  This  AEP  could  also  help  to  validate  potential  cost  and 

weight  reductions.  [Ref.  12:p  78] 

Assuming  the  results  of  the  AEP  are  positive,  the  Marine  Corps,  in  coordination 
with  the  Army,  should  supplement  and  modify  the  AFATDS  software  (in  ADA)  to 
implement  the  Marine  Corps  unique  interfaces.  The  Marine  Corps  should  select  the 
Non-Developmental  Item  (NDI)  equipment  that  most  clearly  fits  its  needs. 
[Ref.  12:p  82] 
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5.      The  Marine  Corps  Viewpoint,  mid  1987 

a.  Why  Should  M  IF  ASS  be  Terminated? 

At  the  time  that  MIFASS  was  terminated,  there  were  several  groups  and 
individuals  within  the  Marine  Corps  that  had  direct  input  into  the  ultimate  fate  of  the 
program.  Many  were  convinced  by  now  that  MIFASS  would  not  work  and  had  been 
searching  for  reasons  why  it  should  be  terminated  rather  than  asking  if  it  should  be 
terminated.  MIFASS  still  had  support,  however,  and  a  strong  consensus  for  or  against 
was  certainly  lacking.  While  opinion  on  the  fate  of  MIFASS  was  divided,  each  of  the 
Marine  agencies  and  commands  had  similar  opinions  on  the  performance  of  MIFASS 
during  testing.  The  one  theme  that  each  appeared  to  express  was  simple:  MIFASS  did 
have  the  potential  to  enhance  Fire  Support  C2  at  higher  levels  of  command,  but  it  was  of 
little  value,  and  indeed  inhibiting,  at  lower  levels.  Unfortunately,  very  little 
documentation  exists  containing  the  thoughts  of  the  decision  makers.  Reliance  must 
instead  be  placed  upon  several  memoranda  containing,  primarily,  the  conclusions  of  the 
agencies  briefing  the  Commandant  at  the  fmal  MIFASS  review  held  on  11  May  1987. 

b.  The  Final  MIFASS  Review,  II  May  1987 

This  section  describes  the  presentations  and  opinions  that  were  delivered 
by  key  participants  at  the  final  review  of  the  MIFASS  program. 

(I)  The  users  perspective:  Colonel  W.  A.  Hesser.  A  key  participant  at 
the  final  review  was  Colonel  W.  A.  Hesser,  Commanding  Officer,  7th  Marines,  whose 
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regiment  was  used  in  the  operational  testing.     His  conclusions,  as  summarized  in  a 
Memorandum  for  the  Record  were: 

1 .  MIFASS  did  not  perform  as  well  as  the  current  manual  system. 

2.  MIFASS  communications  are  inadequate. 

3.  Reliability  is  unacceptable. 

4.  Throughput  and  PLI  (PLRS  Location  Information)  is  inadequate. 

5.  Restricts  mobility  (Especially  infantry  battalion). 

6.  Hard  to  learn  and  troubleshoot. 

7.  Commander  will  not  be  tied  to  console  because  the  console  is  not  adequate  for 
tactical  decision  making.  [Ref.  17:  Appendix  B,  Tab  2] 

Note  the  first  deficiency.   He  does  not  state  that  MIFASS  does  not 

work,  but  only  that  it  doesn't  work  as  well  as  the  current  manual  fire  support  procedures. 

When  asked  by  the  Deputy  Chief  of  Staff  for  Manpower  to  estimate  the  percentage  of 

failure  for  MIFASS  specific  items,  Colonel  Hesser  responded  with  20%.    While  this 

would  be  high  for  an  operational  system,  it  is  not  so  for  an  incomplete  system  that  is  still 

in  the  Full  Scale  Development  phase.   There  was  obvious  concern  that  MIFASS  would 

not  provide  a  significant  advantage  over  current  methods.    In  a  separate  issue  paper, 

Colonel  Hesser  conjectures  on  a  reason  for  the  MIFASS  deficiencies: 

We  decided  to  implement  a  new  doctrine  (the  Fire  and  Air  Support  Center)  along 
with  the  new  system  but  changed  our  mind  three  years  later.  Simply,  the  Corps 
was  never  sure  exactly  what  it  wanted.  [Ref.  18] 
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From  Colonel  Hesser's  viewpoint,  MIFASS  basically  worked.  He 
implied,  however,  that  it  was  not  what  the  Marine  Corps  needed  for  fire  support 
coordination  because  of  the  doctrinal  and  organizational  changes  required  to  make  it 
effective.  Also,  the  existing  communications  equipment  did  not  fully  support  the  needs 
of  the  MIFASS  architecture.  In  a  nutshell,  the  Marine  Corps  got  what  it  asked  for,  but 
not  what  it  needed.  This  was,  in  part,  because  the  Marine  Corps  changed  course  and 
turned  back  to  the  centralized  doctrine  with  the  FSCCs  and  the  DASC  instead  of 
embracing  the  new  FASC  concept  and  a  more  centralized  approach. 

(2)  The  I MAF  Test  Directorate.  Directly  above  Colonel  Hesser  during 
the  operational  testing  was  the  I  MAF8  Test  Directorate.  Their  conclusion  was  that 
"Regiment  and  above  FSCCs  and  the  DASC  can  be  made  to  work  satisfactorily." 
[Ref.  17:Appendix  B]  In  order  to  make  this  feasible,  they  felt  four  things  were  required. 
Of  these  four,  only  two  were  MIFASS  specific:  a  new  computer,  and  software 
cleanup/modification.  Their  only  other  negative  comment  was  that  the  equipment  at  the 
infantry  battalion  and  fire  direction  center  level  was  too  heavy.  Also,  in  their  opinion, 
"MIFASS  worked  somewhat  better  than  generally  perceived  by  most  observers" 
(separation  of  MIFASS  specific  problems  from  the  problems  of  other  systems  is 
necessary).  [Ref.  17:  Appendix  B,  Tab  1] 


8  I  MAF  is  the  First  Marine  Amphibious  Force.    MAF's  were  redesignated  Marine 
Expeditionary  Forces  (MEF's)  in  1987. 
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(3)  Marine  Corps  Operational  Test  and  Evaluation  Activity  (MCOTEA). 

The  analysis  of  the  Marine  Corps  Operational  Test  and  Evaluation  Activity  (MCOTEA) 

is  more  critical  of  MIFASS.   They  state  that: 

MIFASS  does  not  enhance  the  control,  coordination,  and  integration  of  fire  support. 
In  many  respects,  MIFASS  inhibits  the  integration  of  supporting  arms  with  the 
scheme  of  maneuver  of  the  supported  force.  [Ref.  17: Appendix  B,  Tab  3] 

On  the  subject  of  operational  suitability,  they  report  that  "MIFASS 

has  a  significant  adverse  impact  on  infantry  mobility,"  and  "MIFASS  cannot  be  employed 

effectively  in  the  current  organization  and  does  not  meet  the  needs  of  the  commander." 

[Ref.  17:  Appendix  B,  Tab  3]  It  must  be  pointed  out  that  the  "current  organization"  being 

referred  to  is  the  decentralized  doctrine  using  separate  Fire  Support  Coordination  Centers 

and  Direct  Air  Support  Centers.  MIFASS  was  not  intended  to  support  this  decentralized 

approach  and  had  to  be  significantly  reworked  to  make  the  attempt. 

(4)  Required  Operational  Capability  Working  Group.    Another  group 

represented  at  the  final  review  was  the  Required  Operational  Capability  Working  Group. 

While  they  were  originally  organized  to  determine  just  what  the  Marine  Corps  needed 

MIFASS  to  do,  this  is  not  apparent  from  their  recommendations.  The  summary  from  the 

final  review  bears  repeating  here: 

The  current  system  is  not  broke,  organization  and  procedures  are  fundamentally 
sound  and  provide  an  adequate  framework  for  an  integrated  air  &  fire  support 
system.  [Ref.  17:  Appendix  B,  Tab  4] 

The  ROC  working  group  went  on  to  say  that  while  some  assistance 

is  needed  in  fire  support,  it  is  "primarily,  doctrine  and  training."    They  recommended 

"limited  organizational  change     ~  additional  capability  for  the  regimental  FSCC." 
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[Ref.  17:  Appendix  B,  Tab  4]  This  clearly  contradicts  the  FASC  concept  (combined  semi- 
automated  fire  and  air  support  coordination)  that  lies  at  the  core  of  MIFASS.  The  group 
that  was  supposed  to  determine  the  requirements  for  MIFASS  instead  found  that  MIFASS 
was  not  necessary. 

(5)  The  Final  Decision.  Based  on  the  information  and  opinions 
presented  to  him  at  the  final  review,  the  Commandant,  General  P.  X.  Kelley,  decided  on 
the  following  course  of  action: 

1.  Terminate  MIFASS. 

2.  No  immediate  commitment  to  any  Tactical  Data  System  acquisition. 

3.  Expand  requirements  review. 

4.  New  system  definition  study  (evolutionary  development). 

5.  Pursue  enhancements  to  equipment  procurement. 

6.  Deliberate  participation  in  AFATDS.  [Ref.  17:  Appendix  C] 

(6)  The  Embarrassment  of  MIFASS.  Terminating  the  MIFASS  program 
was  embarrassing.  Without  a  doubt,  everyone  concerned  with  MIFASS  felt  a  sense  of 
failure.  As  with  any  failure,  questions  were  asked  and  fingers  were  pointed  back  and 
forth  laying  blame.  There  were  significant  problems  with  the  operation  of  the  MIFASS 
system  during  the  testing.  Even  though  many  of  the  problems  were  not  the  fault  of  the 
contractor  or  MIFASS  specific  hardware/software,  blaming  the  failure  on  the  MIFASS 
system  itself  could  make  the  cancellation  decision  more  palatable.  After  the  termination 
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of  the  program,  it  was  certainly  much  more  common  to  hear  the  phrase  "MIFASS  failed" 
than  it  was  to  hear  "The  Marine  Corps  failed". 

6.      Space  and  Naval  Warfare  Systems  Command  (SPA WAR),  1987 

The  last  briefing  at  the  final  MIFASS  review  came  from  Space  and  Naval 
Warfare  Systems  Command.    Highlights  from  their  brief  to  the  Commandant  include: 

1.  The  full  MIFASS  configuration  was  too  complex  a  first  step. 

2.  The  communications  architecture  used  for  the  MIFASS  EDM  was  high  risk. 

3.  The  slowness  of  operation  masks  MIFASS  functional  utility.  [Ref.  17] 

On  the  subject  of  operational  requirements,  they  "agree  with  the  working  group 
that  decentralization/simplification  was  necessary.  A  single  system  solution  is  not 
necessary  or  desired."  [Ref.  17] 

Within  weeks  of  the  cancellation  of  the  MIFASS   program,  Space  and  Naval 

Warfare  Systems  Command  (SPA WAR)  published  an  overview  of  the  program  and 

lessons  learned  during  the  development.  One  of  the  key  points  made  by  this  report  was 

that: 

The  MIFASS  EDM  generally  met  the  requirements  for  which  it  was  designed.  The 
hardware  units  functioned  as  specified  and  were  suitable  for  the  tactical 
environment  for  which  they  were  intended.  The  software  generally  functioned  as 
intended.  [Ref.  19:p  6-1] 

The  liberal  use  of  the  word  "generally"  reflected  SPAWAR  acknowledgement 

of  some  technical  difficulties,  but  none  apparently  that  were  considered  to  be  major 

failures  of  the  system. 
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The  SPAWAR  report  is  interesting  because  it  does  not  specifically  address  the 
question:  "What  were  the  significant  problems  and  failures  of  the  MIFASS  program?" 
If  the  system  generally  performed  as  it  was  designed,  then  what  was  wrong  with  it  and 
why  was  it  canceled?  This  appears  to  be  another  implied  opinion  that  they  got  what  they 
ordered,  but  not  what  they  needed  or  wanted.  The  report  gives  a  history  of  MIFASS  and 
it  implies  that  MIFASS  development  was  poorly  managed  and,  as  a  result,  was 
excessively  delayed  and  costly.  Delays  and  cost  increases,  however,  were  an  attribute  of 
virtually  every  program  at  that  time.  MIFASS  was  not  canceled  because  it  was  behind 
schedule  and  over  budget.  Although  these  are  legitimate  problems,  the  SPAWAR  report 
fails  to  define  the  real  factors  that  led  to  the  termination  of  the  MIFASS  program. 

Another  interesting  aspect  of  this  report  is  that  it  accepts  no  responsibility  for 
any  of  the  mismanagement  it  attributes  to  the  program.  Everything  is  either  the  fault  of 
the  Marine  Corps  or  the  contractor,  Norden  Systems.  While  it  can  certainly  be  argued 
that  these  two  made  mistakes,  it  is  difficult  to  believe  that  the  Principle  Development 
Activity  (PDA)  is  totally  without  fault,  yet  SPAWAR  considered  themselves  blameless. 

There  is  an  implication  in  the  SPAWAR  report  that  there  were  too  many 
requirements  changes  and  too  many  waivers  approved.  Indeed,  there  were  many  changes 
and  the  waivers  did  number  at  least  200.  Were  all  these  changes  the  problem,  or  were 
they  attempts  at  correcting  other  problems  such  as  poor  initial  requirements  definition? 
Unfortunately,  this  question  can  not  be  answered  within  the  scope  of  this  thesis.  It  is  not 
unreasonable,  however,  to  conjecture  that  the  waivers  were  a  necessary  effort  required  to 
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salvage  a  program  in  trouble,  rather  than  a  result  of  the  simple  inability  of  the  contractor 
to  perform. 

7.      Current  Perceptions,  1987  to  the  Present 

a.  The  Donald  Geving  Thesis 

In  September  of  1987,  Captain  Donald  Geving,  USMC,  devoted  his 
Masters  Thesis  at  the  Naval  Postgraduate  School  to  address  the  failure  of  MIFASS.  Some 
of  his  background  research  has  been  quoted  earlier  in  this  thesis.  His  conclusions 
declared  that  three  major  areas  doomed  the  MIFASS  program: 

1 .  Poor  requirements  definition. 

2.  A  flawed  matrix  organization. 

3.  Interoperability  problems.  [Ref.  8:p  50] 

While  his  first  and  third  conclusions  appear  to  have  merit,  the  emphasis 
that  he  places  on  the  "flawed  matrix  organization"  may  be  excessive.  Was  the 
organization  itself  a  key  contributor  to  the  failure?  Probably  not.  The  next  section  will 
offer  arguments  that  address  why  the  organization  was  merely  a  hindrance  to  the  program. 

b.  Deputy  Program  Manager  for  MAGTF  C2  Systems 

Colonel  Michael  Stankosky,  USMC,  is  the  current  Deputy  PM  for 
MAGTF  C2  systems  at  the  Marine  Corps  Research,  Development,  and  Acquisition 
Command  (MCRDAC)  and  was  a  member  of  the  Research,  Development,  and  Studies 
staff  at  the  time  of  the  final  review  of  MIFASS.  Colonel  Stankosky  has  been  quoted  as 
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saying  that  we  have  failed  miserably  in  the  past  because  we  have  treated  the  development 
of  command  and  control  systems  like  building  a  tank,  for  example,  where  designers  try 
to  complete  complex  systems  at  once.  Rather  than  develop  a  complex  command  and 
control  system  in  one  ambitious  step,  we  should  commit  to  a  gradual  development,  with 
evolutionary  improvements  that  can  build  upon  smaller  successes.  [Ref.  20:p  27] 
This  opinion  is  interesting  because  it  presents  the  idea  that  the  problem  itself  is  too  big. 
A  new  systems  engineering  and  acquisition  methodology  must  be  charted  to  solve  the 
problem  a  little  at  a  time.  His  position  here,  then,  is  that  MIFASS  failed  because  the 
Marine  Corps  tackled  the  problem  all  at  once.  There  is  some  truth  in  this  idea,  to  a 
point,  but  developing  systems  a  piece  at  a  time  may  invite  interoperability  problems  if  a 
well  defined  architecture  is  not  established. 

C.      IDENTIFYING  THE  PROBLEMS  WITHIN  THE  MIFASS  PROGRAM 

1.      Why  the  Program  was  Terminated 

In  May  of  1987,  the  Commandant  was  faced  with  a  MIFASS  system  that  had 
real  deficiencies.  While  some  of  his  key  advisors  still  had  hope,  others  felt  that  the 
system  was  beyond  help  and  no  longer  viable.  Opinion  was  divided.  Had  no  other 
reasonable  alternative  existed,  the  program  probably  would  have  continued  with  major 
modifications.   An  attractive  alternative,  however,  did  exist. 

By  simply  allowing  the  Army  and  the  Marine  Corps  to  both  develop  systems 
to  do  essentially  the  same  tasks,  the  Defense  Department  was  taking  some  risk.  Though 
not  a  deliberate  action,  it  was  laying  the  foundation  for  the  termination  of  one  of  these 
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programs.  If  one  or  the  other  were  to  experience  major  problems,  or  if  the  budget  were 
to  decline,  this  duplication  of  effort  would  become  indefensible.  When  both  of  these 
conditions  occurred,  the  loser  was  MIFASS.  It  is  doubtful  that  this  duplication  was 
intentionally  fostered  in  order  to  ensure  at  least  one  of  the  programs  would  be  successful. 
It  is  more  plausible  that  the  Secretary  of  Defense  was  convinced  of  a  legitimate  need  to 
pursue  different  courses  of  action  due  to  the  divergent  missions  and  procedures  of  the  two 
services  involved. 

The  IDA  study  broke  the  back  of  the  MIFASS  program.  The  Army's 
AFATDS  was  shown  to  be  superior  in  virtually  every  category  of  any  importance.  With 
the  IDA  study  in  hand,  both  the  House  and  Senate  Authorization  Committees  proposed 
to  zero  MIFASS  funding  in  their  versions  of  the  fiscal  1988  Defense  Authorization  Bill. 
[Ref.  21:p  110]  Given  the  mounting  Congressional  and  OSD  pressure  to  cancel 
the  program,  there  was  only  one  rational  conclusion  that  the  Commandant  could  reach: 
recommend  the  termination  of  MIFASS  and  fall  in  with  the  AFATDS  program.  Under 
the  circumstances  of  that  day,  MIFASS  was  properly  and  justifiably  killed.  The  next 
question,  then,  is  "Why  did  AFATDS  look  like  a  better  program  ?"  Simply  put,  it  was 
better  because  the  Army  made  a  few  good  key  decisions  and  the  Marine  Corps  made  a 
few  mistakes.  The  most  significant  of  the  Army's  good  decisions  was  to  develop  the 
software  for  their  AFATDS  program  first  and  the  hardware  last.  The  key  advantage  to 
this  strategy  is  the  availability  of  the  newest  technology  when  the  time  comes  to  decide 
on  hardware.  The  process  of  developing  software  for  MIFASS  took  several  years.  By 
settling  on  hardware  first,  the  Marine  Corps  was  guaranteed  to  have  equipment  that  was 
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outdated  before  it  was  even  fielded.  This  is  obvious  now,  given  a  20/20  hindsight,  but 
the  rapid  pace  of  technological  advances  was  not  so  obvious  then.  The  most  sensible 
approach,  if  there  is  an  idea  of  the  final  architecture,  is  to  proceed  with  software 
development  as  early  as  possible.  [Ref.  22:p  8] 

2.      The  Problems  Within  the  MIFASS  Program 

a.      Common  Weaknesses  in  Defense  Programs 

Several  opinions  on  the  MIFASS  failure  have  been  presented.  Many  of 
these  viewpoints  are  one-sided  perspectives  that  fail  to  see  the  "big  picture".  This  section 
will  sort  through  these  opinions  and  draw  some  conclusions  concerning  which  were  the 
most  significant  of  the  problems. 

It  has  been  established  in  study  after  study  that  there  are  weaknesses 
common  to  nearly  every  Defense  program.  J.  Ronald  Fox,  a  former  Assistant  Secretary 
of  the  Army  responsible  for  procurement,  lists  the  following  trends  as  most  significant: 

1.  Setting   requirements    for   the    most    sophisticated    systems    attainable,    often 
irrespective  of  cost. 

2.  Underestimated  schedules  and  costs  of  major  programs. 

3.  Changes  in  program  and  contract  requirements. 

4.  Lack  of  incentives  for  contractors  and  government  personnel  to  reduce  program 
costs. 

5.  Shortage  of  trained,  quality  personnel.   [Ref.  14:p  32] 
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The  MIFASS  program  is  a  textbook  illustration  of  all  of  these  common 
weaknesses,  as  well  as  several  others.  The  following  paragraphs  provide  evidence  to 
defend  this  claim. 

b.  MIFASS  Tried  to  do  too  Much 

While  MIFASS  may  not  have  been  the  "most  sophisticated  system 
attainable",  there  is  some  evidence  that  it  was  designed  to  do  too  much.  Automation  of 
some  fire  support  tasks  was  a  welcomed  effort,  but  the  designers  of  the  system  lost  the 
support  of  the  users  when  it  was  decided  that  MIFASS  would  accomplish  many  tasks  that 
did  not  need  automation.  Many  at  the  infantry  battalion  level  were  not  amused  that  a 
heavy,  resource  guzzling  system  was  being  developed  to  automate  tasks  at  their  level 
that  were  being  performed  satisfactorily  by  the  current  manual   method. 

c.  Underestimation  of  Schedules  and  Costs 

As  early  as  1982,  it  was  obvious  to  the  Barker  Working  Group  that  the 
contractor  had  underestimated  the  complexity  and  difficulty  of  MIFASS  software 
development.  These  poor  estimations  were  directly  responsible  for  the  cost  and  schedule 
overruns.  Norden  Systems,  however,  does  not  bear  the  full  burden  for  the  lack  of 
accuracy  in  their  estimations.  Norden  was  significantly  handicapped  by  the  lack  of 
decisiveness  within  the  Marine  Corps  concerning  the  application  of  the  FASC  concept. 
This  wavering  of  requirements  led  to  change  after  change.  Norden  apparently  did  not 
have  the  experience  to  predict  this  level  of  requirements  changes. 
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d.  Changes  in  Program  and  Contract  Requirements 

Poor  initial  requirements  definition  was  without  doubt  the  most  serious 
of  the  program  deficiencies.  Without  a  clear  direction  to  pursue,  the  program  changed 
course  time  and  time  again.  New  doctrine  and  procedures  had  not  yet  been  formally 
sanctioned,  yet  a  system  was  already  being  developed  to  support  the  new  concepts. 

When  the  initial  ROC  was  written,  it  concentrated  far  too  heavily  on 
technical  requirements  and  failed  to  identify  the  needs  of  the  Marine  Corps  in  mission 
terms.  This  ROC  was  then  replaced  by  another  in  1979  which  was  also  judged  by  the 
Barker  Working  Group  to  be  without  value.  The  simple  lack  of  a  valid,  realistic 
requirements  document  was  a  devastating  deficiency  of  the  program. 

According  to  Lieutenant  Colonel  Louis  L.  Boros9,  USMC: 

Nearly  one  third  of  the  developmental  costs  of  MIFASS  can  be  attributed  to  the 
"better  mousetrap  syndrome";  that  is,  each  time  the  Marine  Corps  transferred  a 
project  officer,  his  successor  added  to,  or  in  some  way  changed,  the  original  set  of 
requirements.  [Ref.  23:p  42] 

e.  Lack  of  Incentives  to  Reduce  Program  Costs 

Little  could  be  determined  concerning  the  incentives  for  government 
personnel  to  reduce  costs.  Traditionally,  few  incentives  exist,  but  no  information  was 
available  to  confirm  that  this  was  the  case  with  MIFASS. 

The  contractor  had  little  incentive,  if  any,  to  reduce  costs.  The  initial 
MIFASS  contract,  accounting  for  a  large  portion  of  the  funding,  was  a  cost  plus  incentive 


9  Lieutenant  Colonel  Boros  served  as  the  Aviation  C2  officer  with  the  Proponency  & 
Requirements  branch  of  the  MAGTF  Warfighting  Center. 
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fee  contract.  With  the  contractor  guaranteed  to  recoup  approved  costs,  they  had  no  real 
need  to  attempt  to  keep  costs  down.  This  problem  was  recognized  and  all  contracts  after 
the  initial  one  were  written  as  fixed  price. 

/.       Shortage  of  Trained,  Quality  Personnel 

Colonel  Hesser  (CO  of  the  regiment  that  tested  MIFASS)  drew  particular 
attention  to  this  factor  in  an  issue  paper  that  he  presented  to  Major  General  R.  "M" 
Franklin  ,  USMC,  DC/S,  RD&S.  His  stinging  comments  declared  that  "during  the  past 
eight  years  of  MIFASS  development,  not  a  single  MIFASS  acquisition  project  officer  has 
been  promoted...  With  a  single,  non-promotable  officer  at  HQMC  in  charge  of 
development,  the  Marine  Corps  simply  was  not  dedicating  sufficient  assets  to  the 
problem".  [Ref.  18]  The  lack  of  trained  quality  personnel  was  a  key  factor.  The  best 
Marines  simply  did  not  want  to  be  acquisition  project  officers.  There  was  widespread 
belief  that  an  assignment  in  acquisition  was  a  career  setback  that  was  difficult  to  recover 
from.  In  addressing  this  same  issue  in  response  to  Colonel  Hesser' s  comments,  Brigadier 
General  R.  R.  Porter  wrote  "The  acquisition  field  is  not  a  lucrative  one  for  the  majority 
of  officers  because  of  the  perception  that  it  does  not  lead  to  promotion"  [Ref.  24] 
The  allegation  that  none  of  the  MIFASS  ASPOs  were  promoted  enhances  that  perception 
making  it  even  more  difficult  to  dispute. 

g.      Underestimation  of  the  Complexity  of  the  Task 

It  was  recognized  that  the  MIFASS  program  would  push  the  limits  of 
technology.   It  was  a  farsighted  concept  intended  to  anticipate  the  needs  of  the  Marine 
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Corps  in  the  1980's.  The  Marine  Corps  relied  on  Stanford  Research  Institute,  Informatics 
Inc.,  and  Norden  to  provide  realistic,  competent  estimates  of  the  complexity  of  the  task. 
It  does  not  appear  that  the  extensive  software  development  necessary  was  fully  understood 
or  sufficiently  stressed  by  these  contractors. 

h.      Lack  of  Consensus  Concerning  Doctrine 

When  faced  with  complex  problems  that  have  few,  if  any,  precedents, 
senior  managers  often  rely  on  consensus  building  to  determine  the  best  course  of  action. 
In  the  case  of  MIFASS,  achieving  a  consensus  concerning  doctrine  proved  to  be  rather 
difficult.  One  can  only  speculate  on  the  cause  of  this  difficulty.  The  complexity  of  the 
task  was  overwhelming.   The  centralization  issue  can  sharply  divide  opinion. 

i.       The  Marine  Corps  Organization  for  Acquisition 

Most  of  the  principles  involved  have  asserted  in  some  way  or  another  that 
the  matrix  organization  utilized  to  develop  MIFASS  was  a  poor  system.  While  the  matrix 
organization  was  clumsy  and  inefficient,  to  blame  the  failure  of  the  program  on  the 
organization  is  short  sighted.  Certainly,  the  organization  was  weak,  but  the  real  problems 
of  MIFASS  were  rooted  in  other  issues.  There  was  a  stifling  lack  of  consensus 
concerning  doctrine.  This  lack  of  consensus  may  be  partially  attributable  to  the  weakness 
of  the  acquisition  organization.  Captain  Geving  asserted  in  his  thesis  that  the  organization 
caused  a  "decision  strangulation".  This  factor  could  have  accounted  for  the  great 
difficulty  encountered  in  making  the  formal  decision  to  accept  the  FASC  concept  and 
break  cleanly  with  established  decentralized  procedures.    Had  the  FASC  concept  been 
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fully  agreed  upon  and  had  sound  requirements  been  established  at  the  very  beginning,  it 
is  possible,  but  doubtful,  that  the  weakness  of  the  matrix  organization  alone  would  have 
resulted  in  major  problems. 

For  the  most  part,  criticism  of  the  Marine  Corps  acquisition  organization 
focused  on  three  claims: 

1.  No  one  was  "in  charge". 

2.  Management  by  committee  was  inefficient  and  ineffective. 

3.  MIFASS  suffered  from  "decision  strangulation"  because  of  the  large  number  of 
people  who  could  effectively  veto  decisions.  [Ref.  25:p  134] 

"Management  by  committee"  did  appear  to  be  a  drawback.  The  lack  of 
clear  command  channels  was  a  problem  typical  of  the  majority  of  the  defense  acquisition 
programs  prior  to  the  Defense  Reorganization  Act  of  the  late  1980's.  There  is  little 
evidence,  however,  to  support  the  other  claims. 

The  most  valid  criticism  of  this  organization  would  be  that  it  was  slow 
to  react  to  the  problems  within  the  MIFASS  program.  Virtually  insurmountable  problems 
should  have  been  obvious  from  the  beginning.  Recognizing  and  coping  with  these 
problems  was  a  slow  and  tedious  process  involving  a  lot  of  people.  But  Marines  did 
recognize  the  problems.  Marines  did  recommend  solutions  and  decisions  were  made  to 
implement  or  ignore  those  recommendations. 

While  day  to  day  program  management  by  committee  may  have  been 
cumbersome  there  was  certainly  "someone  in  charge"  from  a  big  picture  point  of  view. 
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Numerous  Acquisition  Decision  Memoranda  (ADM)  were  published  outlining  key  strategy 
decisions.  The  correctness  of  those  decisions,  however,  rested  on  the  shoulders  of  the 
decision  maker.  Given  the  best  advice  in  a  timely  manner,  the  decision  maker  can  still 
make  the  wrong  decision.  The  acquisition  organization  appears  to  have  presented  the 
decision  makers  with  sufficient  information  to  make  the  right  decision.  In  many  cases, 
choices  were  made  that,  given  the  benefit  of  hindsight,  appear  to  have  been  wrong. 

Political  pressures,  cognitive  bias,  personal  agenda,  and  parochial  attitudes 
all  could  have  contributed  to  those  decisions.  The  impact  of  these  factors  is  certainly 
difficult  to  assess,  but  they  provide  a  likely  explanation  for  making  the  "wrong"  decision 
when  given  all  of  the  information  necessary  to  choose  correctly. 

D.      CONCLUSIONS  AND  LESSONS  LEARNED 

1.      Conclusions 

The  Commandant  of  the  Marine  Corps  made  the  correct  decision  in  1987. 
MIFASS  was  indefensible  from  a  budgetary  standpoint  and  it  was  not  what  the  Marine 
Corps  needed  at  the  time. 

There  were  four  key  problems  within  the  MIFASS  program: 

1.  A  lack  of  consensus  concerning  the  doctrinal  issue  of  centralization  versus 
decentralization. 

2.  Unstable  requirements  definition  that  failed  to  state  requirements  in  mission  terms. 

3.  Underestimation  of  the  complexity  of  the  task. 

4.  Adherence  to  the  traditional  approach  of  concentration  on  hardware  first  and  then 
the  software. 
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The  clumsy  and  inefficient  management  system  was  a  hindrance  to  the 
program,  but  the  only  devastating  problem  was  the  lack  of  the  foundation  necessary  to 
establish  the  program  in  the  first  place:  sound  initial  requirements  definition  based  on 
appropriate  doctrine. 

The  unfounded  initial  definition,  and  the  failure  to  agree  on  doctrinal 
justification  that  followed,  led  to  interoperability  problems,  cost  increases,  and  program 
delays.  By  1987,  the  MIFASS  program  was  the  victim  of  the  Serengeti  Phenomenon10: 
the  slowest  thing  on  the  plain  in  the  morning  is  breakfast  and  anything  that  limps,  dies. 
MIFASS  limped,  AFATDS  did  not. 

2.      Lessons  Learned 

The  Marine  Corps  has  learned  many  lessons  from  the  failure  of  MIFASS.  The 
old  matrix  organization  has  been  replaced  with  a  dramatically  different  acquisition  system. 
In  response  to  the  Gold  water-Nichols  Reorganization  Act  of  1986,  and  the  termination  of 
MIFASS  in  1987,  the  procurement  business  in  the  Marine  Corps  has  been  radically 
changed.  A  thorough  description  of  this  new  acquisition  organization  is  presented  in 
Chapter  III  of  this  thesis. 

Hopefully,  a  lesson  has  been  learned  concerning  requirements  definition.  The 
recently  published  Marine  Corps  Directive  on  Acquisition  drives  the  point  home: 


The  Serengeti  Phenomenon  was  a  term  used  by  Radm  Flanagan,  USN, 
Superintendent's  Guest  Lecturer,  NPS,  October  1990,  in  reference  to  the  ill-fated  Navy 
P-7  Anti-submarine  Warfare  aircraft. 
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The  ROC  should  identify  operational  requirements  not  hardware  solutions.  It 
should  provide  a  range  of  values  vice  a  fixed  point  requirement.  A  poorly  written 
ROC  will  overly  constrain  potential  alternatives  for  meeting  the  operational 
requirements  and  will  jeopardize  the  success  of  the  acquisition  program. 
[Ref.  26:p  9-5] 

It  is  unlikely  that  new  Marine  Corps  systems  will  try  to  tackle  so  much  at  one 

time  in  the  future.  Wary  of  falling  into  that  trap  again,  current  Marine  Corps  philosophy 

embraces  the  ideas  of  modular,  evolutionary  acquisition  using  non-developmental  items 

as  much  as  possible.  The  "build  a  little,  test  a  little,  field  a  little"  approach  will  be  used 

to  prevent  another  MIFASS  from  happening.  Overall,  the  Marine  Corps  responded  to  the 

MIFASS  failure  in  a  big  way.  A  description  of  that  response  follows  in  Chapter  III.  Will 

the  response  be  sufficient  to  prevent  further  disappointments?  That  is  one  of  the  driving 

questions  behind  this  assessment  effort. 
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HI.   MTACCS  TODAY:  THE  RESPONSE  TO  MIFASS 

A.      INTRODUCTION 

The  United  States  Marine  Corps  is  a  proud  organization.  The  failure  of  MIFASS 
was  not  taken  lightly.  The  response  to  that  failure  would  be  far  reaching,  but  MIFASS 
was  not  the  only  factor.  There  were  many  contributing  factors  that,  when  summed 
together,  virtually  demanded  a  reorganization  of  the  acquisition  system.  The  Goldwater- 
Nichols  Reorganization  Act  of  1986",  the  embarrassment  of  MIFASS  in  May  1987,  the 
appointment  of  a  new  Marine  Corps  Commandant,  General  Alfred  M.  Gray  on  1  July 
1987,  and  the  completion  of  a  critical  report  by  the  Naval  Research  Advisory 
Committee12,  were  all  key  contributors.  Together  they  forced  sweeping  organizational 
changes  throughout  the  Marine  Corps. 

Several  initiatives  were  undertaken  to  strengthen  the  Marine  Corps  in  its  combat 
effectiveness  and  in  its  management  of  defense  resources.  The  scope  of  these  initiatives 
was  rather  broad,  but  some  of  the  more  important  objectives  can  be  summarized  as 
follows: 


1.     Revitalize  the  MTACCS  concept  to  correct  the  deficiencies  identified  by  both  the 
MIFASS  failure  and  the  Naval  Research  Advisory  Committee  (NRAC). 


The  Goldwater-Nichols  Reorganization  Act  forced  major  changes  on  Defense 
acquisition.   It  is  discussed  in  greater  detail  in  Section  E  of  this  chapter. 

The  NRAC  report  on  Intra/Interoperability  deficiencies  within  MTACCS  is 
addressed  in  more  detail  in  Chapter  VII. 
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2.  Reorganize  the  acquisition  organization  within  the  Marine  Corps  to  capitalize  on 
the  lessons  learned  from  MIFASS  and  to  comply  with  the  Goldwater-Nichols 
Reorganization  Act. 

3.  Implement  several  warfighting  enhancement  initiatives  (such  as  the  addition  of  a 
fourth  rifle  company  to  each  infantry  battalion). 


The  numerous  warfighting  enhancement  initiatives  will  have  a  significant  impact 
on  the  requirements  of  MTACCS.  They  are  mainly  organizational  and  equipment  changes 
designed  to  provide  the  most  efficient  distribution  of  Marine  Corps  assets.  Assessment 
of  these  initiatives,  however,  is  beyond  the  scope  of  this  thesis. 

This  chapter  will  focus  on  defining  three  key  issues: 

1.  The  current  MTACCS  concept. 

2.  A  configuration  management  tool  called  the  Field  Development  System  (FDS). 

3.  The  current  MTACCS  acquisition  and  development  organization  and  methodology. 

B.   THE  "REVITALIZED"  MTACCS  CONCEPT 

1.      The  Need  for  Reevaluation 

In  the  past,  MTACCS  was  defined  as  a  "conceptual  association  of  C2  systems 
to  support  tactical  operations  using  where  feasible,  common  equipment,  operational 
procedures,  databases,  and  design  philosophy...."  [Ref.  3:p  1-1]  Exactly  what  that  meant 
is  unclear  now  and  was  probably  unclear  even  to  those  who  wrote  it  more  than  eleven 
years  ago.  To  many  people,  "a  conceptual  association"  meant  that  MTACCS  subsystems 
were  developed  somewhat  independently  with  little  regard  for  interoperability  and 
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configuration  management.  In  fact,  this  appears  to  have  been  the  majority  belief. 
MTACCS  was  developed  from  the  outset  in  just  that  way  and  serious  deficiencies  and 
setbacks  ensued.  By  1988,  the  program  had  ground  virtually  to  a  halt.  MIFASS  had 
been  terminated,  Congress  had  passed  the  Goldwater-Nichols  Reorganization  Act,  and  it 
appeared  that  the  time  had  come  to  step  back  and  reevaluate  the  entire  MTACCS  concept. 
As  a  result  of  this  reevaluation,  efforts  have  been  undertaken  to  update  the  original 
MTACCS  concept  into  the  planned  Marine  Corps  Command,  Control,  Communications, 
Computers,  Intelligence,  and  Interoperability  (C4I2)  Architecture.13  [Ref.  27:p  8] 

2.      The  Vision  of  General  Gray 

A  key  objective  of  the  new  Commandant  would  be  to  develop  a  Marine  Corps 
that  is  lighter  "making  both  Marines  on  the  ground  and  the  gear  in  their  hands  more 
mobile  and  more  lethal".  [Ref.  28:p  15] 

In  General  Gray's  view,  attrition,  firepower,  and  frontal  assault  are  no  longer 
the  key  to  combat  success;  superior  technology,  purposeful  movement,  the  application  of 
combat  power  at  the  proper  time  and  place,  initiative  and  the  influence  of  commanders 
through  their  command,  control,  communications,  and  intelligence  will  allow  Marines  to 
engage  any  enemy  and  win.  [Ref.  29:p  107] 

These  ideas  will  have  a  significant  impact  on  the  development  of  MTACCS 
component  systems.  Someone  once  said  "For  every  vision,  there  is  an  equal  but  opposite 


13  Quoting  from  Signal  magazine,  "In  1988,  the  Marine  Corps  merged  the 
inextricably  entwined,  but  often  estranged,  military  disciplines  -  communications  and 
intelligence.  The  Corps,  acknowledging  this  as  a  "bold  move",  went  even  further  by 
adding  the  seemingly  intractable  field  of  intelligence  interoperability."  [Ref.  29:p  107] 


54 


revision".  While  some  may  feel  that  user  support  for  MTACCS  will  wane  with  General 
Gray's  retirement  in  June  of  1991,  there  is  evidence  that  MTACCS  will  continue  to 
maintain  its  course. 

It  is  General  Gray's  belief  that  MTACCS  decisions  have  been  made  based  on 
the  input  of  all  of  the  senior  leadership  and  he  is  confident  that  the  focus  of  the  Marine 
Corps  will  be  maintained.    [Ref.  28:p  16] 

3.      The  Definition  of  MTACCS 

a.      The  Difficulty  of  Definition 

Clear  self  expression  is  a  trait  that  is  dying  in  America14.  The  numerous 
documents  and  publications  that  describe  both  MTACCS  and  the  Field  Development 
System  (FDS)  are  heavily  crowded  with  a  multitude  of  obscure  terminology.  The 
excessive  use  of  acronyms,  vague  cliches,  and  "buzzword"  phrases,  significantly  hampers 
any  attempt  at  developing  a  thorough  understanding.  In  his  book  Command,  Control,  and 
the  Common  Defense.  Lieutenant  Colonel  C.  Kenneth  Allard,  USA,  echoed  this  opinion 
when  he  wrote  "The  writings  by  experts  in  the  field  of  command  and  control  can  be  an 
impenetrable  thicket  of  buzzwords,  jargon,  and  obscure  usages."  [Ref.  30:p  148] 
This  problem  remains  ubiquitous.  It  is  not  merely  a  trivial  nuisance.  The  simple  lack  of 
a  clear,  understandable  program  definition  can  be  devastating  to  a  project.  With  this 
limitation  in  mind,  the  "revitalized"  MTACCS  concept  is  herein  defined. 


14         Paraphrased    from    Dr.    Donald    Abenheim,    Naval    Postgraduate    School, 
12  January  1991. 
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b.  Key  Elements  of  MAGTF  C2 

The  Commandant  of  the  Marine  Corps  has  identified  several  key  elements 
that  are  required  to  support  the  Marine  Air  Ground  Task  Force  (MAGTF).  These 
elements  include: 

1 .  The  tactical  command,  control,  communications,  and  intelligence  (C3I)  systems  for 
Ground  C2,  Aviation,  C2,  and  Combat  Service  Support  C2. 

2.  Approved  C2  architectures  that  synthesize  the  placement  and  use  of  tactical 
Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems. 

3.  Supporting  communications  equipment. 

4.  Command,   control,   communications,   and   intelligence   (C3I)   systems   aboard 
amphibious  ships. 

5.  Common  hardware  and  software  building  blocks. 

6.  Interoperability  requirements  and  standards  programs. 

7.  A  strong  configuration  management  process  that  does  not  allow  perturbations  of 
the  elements  unless  the  impact  on  the  whole  is  assessed.  [Ref.  27: p  1] 

MTACCS  is  the  "umbrella  concept"  intended  to  provide  these  elements 
to  the  MAGTF  commander.  [Ref.  27:p  2] 

c.  The  MTACCS  Concept 

The  MTACCS  program  will  be  pursued  as  a  series  of  integration  phases. 
Each  phase  will  merge  the  numerous  developing  and  disparate  components  and 
subsystems  into  a  consistent  system  that  achieves  a  predetermined  level  of  integration. 
[Ref.  31]  Instead  of  building  MTACCS  in  one  ambitious  step,  the  Marine  Corps 
will  gradually  build  the  system  by  making  evolutionary  improvements  in  computer 
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software  and  hardware  during  each  phase.  [Ref.  20:p  27]  These  integration  phases  will 
be  called  Field  Development  System  events.  FDS  1  is  the  first  of  these  events.  The 
Field  Development  System  is  described  in  detail  in  Section  D  of  this  chapter. 

The  MTACCS  Operational  Concept  Document  was  published  on  3  April 
1990.  That  document  "defines  MTACCS,  outlines  the  operational  concept,  describes 
MTACCS  component  systems,  and  provides  a  concept  for  development/acquisition". 
[Ref.  1] 

In  the  Operational  Concept,  MTACCS  is  defined  as  "the  integration  of 
separate  automation  assisted  MAGTF  Command  and  Control  (C2)  Systems  which  support 
tactical  operations."  [Ref.  1]  It  is  important  to  stress  that  MTACCS  is  a  concept  only. 
It  is  the  integration  of  component  systems  to  allow  those  systems  interoperability  in  order 
to  provide  integrated  and  automated  support  for  MAGTF  C2.  [Ref.  32:p  3] 
"MTACCS  will  achieve  interoperability  among  automated  systems  by  utilizing  a  common 
family  of  data  processing  hardware,  a  common  operating  system  and  support  software." 
[Ref.  33:p  1]   MTACCS  is  an  engineering  effort  to: 

1.  Select  common  hardware  and  software. 

2.  Select  MTACCS  architecture. 

3.  Test  the  architecture. 

4.  Manage  the  integration  of  the  component  systems.  [Ref.  33:p  1] 

Rather  than  simply  allow  for  a  vague  "conceptual  association,"  MTACCS  is  expected  to 
"integrate"  the  separate  systems.   Now  the  role  of  MTACCS  is  better  defined. 
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Separate  C2  systems  will  be  developed  for  each  of  the  four  functional 


areas: 


1.  Ground  C2:  Tactical  Combat  Operations  (TCO),  Multi-service  Advanced  Field 
Artillery  Tactical  Data  System  (MAFATDS). 

2.  Aviation  C2:  Marine  Air  Command  and  Control  System  (MACCS). 

3.  Combat  Service  Support  (CSS)  C2:  Marine  Integrated  Personnel  System  (MIPS), 
Marine  Integrated  Logistics  System  (MILOGS). 

4.  Intelligence:  Marine  Air-Ground  Intelligence  System  (MAGIS). 


Figure  6  depicts  the  MTACCS  concept.  The  Tactical  Combat  Operations  (TCO)  system 
will  be  the  hub  of  MTACCS  and  is  the  system  intended  for  MAGTF  command  and 
control.  As  such,  TCO  is  intended  to  be  the  system  that  integrates  the  component 
systems  of  MTACCS. 

d.      The  MTACCS  Architecture 

Pacific  Northwest  Laboratories  (PNL)  is  the  system  engineer  and 
integrator  for  MTACCS.  PNL  is  responsible  for  architecture  development  and 
implementation,  system  requirements  definition  and  standards  development,  systems 
engineering  and  development,  and  configuration  management.  [Ref.  34:p  iii] 

The  proposed  architecture  has  been  defined  in  a  draft  hardware/software 

recommendation  prepared  by  PNL.  This  architecture  consists  of  four  layers  as  shown  in 

Figure  7. 

The  hardware  layer  will  be  comprised  of  a  family  of  computers  whose  varying 
capabilities  will  be  matched  against  the  varying  needs  of  different  echelon  levels. 
MTACCS  Common  Application  Support  Software  (MCASS)  envelops  the  two 
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Figure  6:  The  MTACCS  Concept  [Source:  MCCDC] 

middle  layers  which  consist  of  System  Support  Software  and  Command  and  Control 
Software  and  will  be  the  foundation  upon  which  MTACCS  software  will  be  built. 
System  Support  Software  will  provide  a  uniform  development  approach  and  will 
rely  on  Commercial-Off-The-Shelf  Software  (COTS)  to  the  maximum  extent 
possible.  Command  and  Control  Support  Software  will  capitalize  upon 
developments  made  by  the  Army's  CASS  program.  The  Command  and  Control 
Applications  Software  Layer  will  contain  those  common  applications  that  provide 
common  functionality  across  two  or  more  MTACCS  nodes.  It  will  be  comprised 
of  software  developed  by  Air,  Ground,  Intelligence,  and  Combat  Service  Support 
programs.  These  applications  fall  under  the  umbrella  of  MTACCS  software  which 
will  facilitate  communications  between  the  various  applications  and  provide  an 
overall  battle  situation  picture  for  the  command  and  control  facilities  of  the 
MTACCS. 
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Figure  7:  MTACCS  Four  Layer  Architecture  [Source:  Ref.  34] 

An  important  goal  of  the  MTACCS  philosophy  is  to  develop  common  software 
for  levels  two  and  three,  and  common  application  software  for  each  functional  area 
at  level  four.  The  end  result  of  the  common  building  block  approach  for  MTACCS 
is  to  lower  development  and  production  costs,  enable  common  training  and 
maintenance,  lower  support  costs,  reduce  complexity,  and  increase  interoperability. 
[Ref.  34:p  2.3-2.4] 


C.      THE  CURRENT  STATUS  OF  MTACCS  COMPONENT  SYSTEMS 

1.      MAGTF  C2 

The  capstone  of  MTACCS  will  be  the  system  which  provides  integration  of 
all  the  other  component  systems.    At  the  current  time,  such  a  system  does  not  exist, 
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although  it  is  conceived  to  be  a  derivation  of  the  Tactical  Combat  Operations  (TCO) 
system.  The  TCO  system  is  currently  in  the  conceptual  stage  and  will  receive  much  of 
its  definition  through  the  Field  Development  System  (FDS).  [Ref.  2:p  1-6]  The 
anticipated  TCO  development  schedule  is  shown  in  Figure  8. 


FY             1990 

1991 

1992 

1993 

1994 

QTR            2     3     4 

12     3     4 

12     3     4 
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Figure  8:  TCO  Development  Schedule  [Source:  Ref.  32] 

TCO  will  provide  MAGTF  commanders  at  all  echelons  with  specific  tactical 
applications  software  programs  which  will  build  on  common  hardware  and  software. 
These  applications  will  include  tools  such  as: 


1.     Display  of  Position  Location  Information   (PLI)  extracted  from  PLRS/GPS 
systems. 
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2.  Information  on  the  friendly  situation  and  resources  extracted  from  the  MIPS  and 
MILOGS  systems. 

3.  Information  on  the  supporting  arms  situation  extracted  from  the  Multi-service 
Advanced  Field  Artillery  Tactical  Data  System  (MAFATDS)  system. 

4.  Summary  information  on  the  enemy  situation  extracted  from  the  MAGIS  system. 
[Ref.  32:p  B-l] 


2.      Ground  C2 

The  major  component  systems  of  Ground  C2  include  the  Tactical  Combat 

Operations  (TCO)  system  and  the  Multi-service  Advanced  Field  Artillery  Tactical  Data 

System  (MAFATDS).  At  this  level,  TCO  will  primarily  support  infantry,  tank,  engineer, 

and  reconnaissance  units  while  MAFATDS  will  support  the  fire  support  units  (artillery, 

mortar,  and  naval  gunfire).  TCO  is  still  in  the  conceptual  stage.  The  focus  of  TCO  will 

be  the  development  of  a  common  situation  picture  to  support  ground  combat  unit 

commanders  and  operations  personnel.  MAFATDS  is  a  proposed  adaptation  of  the  Army 

Advanced  Field  Artillery  Tactical  Data  System  (AFATDS).  AFATDS  recently  underwent 

a  concept  evaluation  and  is  currently  undergoing  further  development  by  the  Magnavox 

Electronic  Systems  Company.  [Ref.  2:p  1-6]  The  General  Accounting  Office  reported  in 

1989  that: 

Fielding  AFATDS...is  scheduled  for  the  fourth  quarter  of  fiscal  year  1992. ..the 
schedule  appears  to  be  optimistic  considering  the  significant  software  development 
still  required.... [Ref.  5:p  13] 

MAFATDS  is  expected  to  be  fielded  in  the  1994  time  frame.  Currently,  Fleet 

Marine  Force  (FMF)  units  have  an  interim  system,  FIREFLEX,  which  will  be  used  until 
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MAFATDS  becomes  available.  [Ref.  2:p  1-6]  The  anticipated  MAFATDS  development 
schedule  is  shown  in  Figure  9.  [Ref.  32:p  B-2] 
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Figure  9:  MAFATDS  Development  Schedule  [Source:  Ref.  32] 

3.      Aviation  C2 

The  major  component  systems  of  Aviation  C2  include  the  Advanced  Tactical 
Air  Command  and  Control  Central  (ATACC),  the  Tactical  Air  Operations  Module 
(TAOM),  the  Improved  Direct  Air  Support  Center  (IDASC),  and  the  Marine  Air  Traffic 
Control  and  Landing  System  (MATCALS).  [Ref.  2:p  1-7] 

ATACC  is  being  developed  to  support  the  operations  and  planning  functions 
of  the  Tactical  Air  Command  Center  (TACC),  the  senior  Marine  aviation  combat 
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operations  center  in  the  MAGTF.  The  TACC  exercises  command  over  MAGTF  air 
operations,  generates  daily  air  tasking  orders,  plans  the  air  campaign,  and  is  the  principle 
MAGTF  interface  with  joint  and  combined  C2  agencies  [Ref.  32:p  B-3].  ATACC  is 
scheduled  to  be  available  in  1992  [Ref.  2:p  1-7].  The  anticipated  ATACC  development 
schedule  is  shown  in  Figure  10. 
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Figure  10:  ATACC  Development  Schedule  [Source:  Ref.  32] 

TAOM  is  currently  in  production  and  has  been  designated  to  replace  the 
ANATQ-2  and  ANATYQ-3A15  at  the  Tactical  Air  Operations  Center.  TAOM  is  capable 


The    AN/TYQ-2    and    AN/TYQ-3A    are    communications    and    computer 
components  of  the  TAOC. 
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of  performing  all  operational  air  defense  tasks  and  is  currently  deployed  in  Saudi  Arabia 
in  support  of  Operation  Desert  Storm. 

IDASC  is  designed  to  support  the  Direct  Air  Support  Center  (DASC)  tasks  of 
coordinating  assault  support,  close  air  support  strikes,  and  air  reconnaissance  missions 
with  other  fire  support  means.  The  DASC  product  improvement  program  will  incorporate 
selected  automation  measures  to  improve  system  performance.  Phased  improvements  to 
IDASC  include: 


1.  Electronic  mapping  capability,  i.e.,  replacement  of  paper  map-manual  plot  with 
electronic  projection  map  and  electronic  automated  assistance  (computer)  plot. 

2.  Status  board  automation,  i.e.,  replacement  of  plexiglass  status  boards  (one  dealing 
with  fixed  wing  and  the  other  with  rotary  wing)  and  manually  transcribed  data 
information/updates  with  electronic  displays  at  appropriate  operator  stations  (fixed 
wing  status  display/rotary  wing  status  displays)  and  electronic  automated 
assistance  input  control  devices  (computers)  to  control  fixed  and  rotary  wing  status 
input/display. 

3.  Automation  of  the  Air  Tasking  Order  (ATO)  to  include  receipt,  dissemination, 
update,  etc. 

4.  Automation  assistance  for  receipt  of  digital  (DCT  type)  messages  (Tactical  Air 
Requests  (TAR),  Helo  Requests  (HR),  etc.) 

5.  Automatic  incorporation  of  Position,  Location,  Reporting  System  (PLRS)  data  into 
the  DASC  electronic  map/projection  system. 

6.  Automated  assistance  in  journaling,  recording  traffic,  printing,  etc. 

7.  Downsizing  (transitioning  to  lighter  equipment  and  smaller  mobile  shelters). 
[Ref.  2:p  1-7] 


The  product  improvement  schedule  is  shown  in  Figure  1 1 . 
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Figure  11:  IDASC  Product  Improvement  Schedule  [Source:  Ref.  32] 

4.      Combat  Service  Support  C2 

The  major  component  subsystems  of  Combat  Service  Support  C2  include  the 
Marine  Integrated  Personnel  System  (MIPS),  the  Marine  Integrated  Logistics  System 
(MILOGS),  and  the  Improved  Force  Automated  Services  Center  (IFASC)  [Ref.  2]. 

MIPS  will  provide  the  FMF  commanders  essential  near  real  time  personnel 
information  through  its  interface  with  TCO.  MIPS  will  employ  the  Unit  Commander's 
Personnel  System  (UCPS)  as  the  source  of  data  to  provide  to  TCO  and  the  MAGTF  C2 
system.  UCPS  is  currently  available  and  being  used  by  FMF  units.  The  MIPS  interface 
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with  UCPS  and  TCO  is  conceptual  and  will  be  developed  throughout  the  FDS  series. 
[Ref.  2]  The  MIPS  anticipated  development  schedule  is  shown  in  Figure  12 
[Ref.  32:p  B-5]. 
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Figure  12:  MIPS  Development  Schedule  [Source:  Ref.  32] 

MILOGS  will  employ  the  LOG  II  AIS16  systems  and  integrate  their  output 
to  provide  the  information  required  by  TCO  and  the  MAGTF  C2  system.  LOG  II  AIS 
systems  currently  exist  and  are  being  used  within  FMF  units.  The  MILOGS  interface 
with  LOG  II  AIS  and  TCO  is  also  conceptual  and  will  be  developed  throughout  the  FDS 
series.     The  ongoing  U.S.  Army  Combat  Service  Support  Control  System  (CSSCS) 


16 


The  second  generation  automated  logistics  information  system. 
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development  is  being  closely  monitored.  Maximum  advantage  of  Army  development 
efforts  will  be  taken  in  defining  and  developing  MILOGS  and  will  be  incorporated  into 
the  FDS  series.  It  is  anticipated  that  the  CSSCS  development  schedule  will  not  permit 
the  use  of  CSSCS  functionality  in  FDS  1.  [Ref.  2:p  1-7]  The  anticipated  MILOGS 
development  schedule  is  shown  in  Figure  13  [Ref.  32:p  B-5]. 
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Figure  13:  MILOGS  Development  Schedule  [Source:  Ref.  32] 

5.      Intelligence 

The  Intelligence  Analysis  System  (IAS),  currently  under  development,  will  be 
incorporated  into  FDS  1  and  following  FDS  events  as  appropriate.  Interfacing  to  the  IAS 
will  be  facilitated  for  FDS  1  since  the  computer  hardware,  tools,  etc.,  upon  which  the  IAS 
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are  hosted  are  the  same  basic  building  blocks  that  will  be  utilized  for  TCO,  MIPS,  and 
MILOGS.  IAS  serves  as  the  fusion  center  for  the  multiple  intelligence  sources  available 
to  the  MAGTF. 

Intelligence  systems  and  agencies  that  provide  input  to  the  Intelligence 
Analysis  System/Intelligence  Analysis  Center  (IAS/IAC)  are  shown  in  Figure  14. 
Included  are  the  Technical  Control  and  Analysis  Center  (TCAC),  Tactical  Electronic 
Reconnaissance  Process  and  Evaluation  System  (TERPES),  Topographic  platoon, 
Reconnaissance  units  (Force  and  Division),  the  Imagery  Interpretation  Facility  (IIF), 
Imagery  Processing  (IP)  segment,  Remotely  Piloted  Vehicle  (RPV)  system,  Interrogator 
Translator  Teams  (ITT),  Counter  Intelligence  Teams  (CIT),  Joint  Service  Imagery 
Processing  System  (JSIPS),  Remote  Ground  Sensors/Tactical  Remote  Sensor  System 
(RGS/TRSS). 

The  interaction  between  IAS  and  TCO  is  conceptual  at  this  time  and  will  be 
defined  and  developed  during  the  FDS  series.  [Ref.  2:p  1-7]  The  anticipated  IAS  block 
upgrade  development  schedule  is  shown  in  Figure  15.  [Ref.  32:p  B-4]. 

6.      Communications 

The  MTACCS  Master  Acquisition  Plan  identifies  several  communications 
systems  that  are  of  vital  importance  to  the  success  of  MTACCS: 


1.  AN/PSC-2  Digital  Communications  Terminal  (DCT).  A  light  weight,  handheld, 
programmable  message  processor  that  plugs  into  standard  Marine  Corps  Radios. 

2.  Position  Location  Reporting  System  (PLRS).  A  system  of  digital  UHF  radios  that 
will  automatically  provide  commanders  with  accurate,  near  real  time  identification 
and  location  data  on  assigned  forces. 
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"igure  14:  Marine  Air/Ground  Intelligence  Systems  [Source:  Ref.  32] 

3.  Global  Positioning  Systems  (GPS).  A  spaced  based  radio  navigation  system  that 
provides  position,  velocity,  and  time. 

4.  Unit  Level  Circuit  Switch  (ULCS).   A  family  of  digital  equipment  that  provide 
automatic  switching  service  and  subscriber  service  functions. 

5.  Unit  Level  Tactical  Data  Switch  (ULTDS).    A  team  transportable,  12  line  data 
switch. 

6.  Single  Channel  Ground  Air  Radio  System  (SINCGARS).    A  VHF-FM  single 
channel,  frequency  hopping  radio  used  to  transmit  voice  and  data. 

7.  AN/MRC-142.   A  secure,  VHF,  digital,  multichannel  radio  for  voice  and  data. 

8.  ANATRC-170.   A  SHF  troposcatter  multichannel  radio.  [Ref.  21] 
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Figure  15:  IAS  Development  Schedule  [Source:  Ref.  32] 

All  but  the  ULTDS  are  in  production.  These  systems  are  intended  to  provide 
the  necessary  communications  throughput  to  sustain  at  least  early  versions  of  MTACCS. 
It  is  recognized  that  the  capabilities  of  these  systems  may  be  exceeded  as  the  MTACCS 
integration  matures. 

The  anticipated  communications  architecture  is  shown  in  Figure  16. 
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Figure  16:  MTACCS  Communications  Architecture  [Source:  Ref.  34] 


72 


D.      THE  FIELD  DEVELOPMENT  SYSTEM  (FDS) 

1.      Background 

MTACCS  was  defined  earlier  as  an  "engineering  effort"  intended  to 
accomplish,  among  other  objectives,  management  of  the  integration  of  MTACCS 
component  systems.  The  Field  Development  System  project  is  a  key  component  of  that 
engineering  effort. 

The  Field  Development  "System"  would  perhaps  be  better  described  as  a 
"process"  or  "methodology".  FDS  is  based  on  promoting  a  strong  working  relationship 
between  the  FMF  user,  Marine  Corps  developers,  and  private  industry.  [Ref.  35 :p  iii]  It 
is  a  strategy  for  including  the  user  in  the  process  of  identifying  and  validating 
requirements  for  an  integrated  command  and  control  automated  support  system. 
Figure  17  details  the  FDS  approach.  As  shown  in  Figure  18,  FDS  will  be  a  series  of 
events.  Specific  goals  will  be  established  for  each  FDS  event.  During  that  event,  the 
available  version  of  all  component  subsystems  will  be  brought  to  the  FDS  site.  The 
systems  will  be  integrated  to  the  level  necessary  to  achieve  the  objectives  of  that  event. 
Once  those  objectives  are  achieved  and  the  system  is  evaluated  to  be  ready,  a  working, 
integrated  system  is  delivered  to  the  fleet  users.  Colonel  Michael  Stankosky,  the  current 
deputy  program  manager  for  MAGTF  Command  and  Control  Systems,  feels  that  the 
evolutionary  design  of  the  system  will  allow  the  Marine  Corps  to  deploy  basic  versions 
of  MTACCS  early  on.  Information  from  field  testing  will  help  designers  overcome  errors 
and  technical  difficulties  by  gradually  building  upon  successes.  [Ref.  20:p  27]  The 
Marine  Corps  Tactical  Systems  Support  Activity   (MCTSSA)   at  Camp  Pendleton, 
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Figure  17:  FDS  Approach  [Source:  Ref.  32] 
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Figure  18:  FDS  Evolutionary  Strategy  [Source:  Ref.  32] 
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California,  has  been  selected  as  the  site  for  the  first  event,  FDS  1,  scheduled  to  be 
conducted  in  early  1991  [Ref.  2]. 

2.      Guidance  Framework 

In  order  to  assure  long  term  value  and  consistency  between  each  Field 
Development  System  event,  a  Guidance  Framework  has  been  established  prior  to  initiation 
of  FDS  1.  Key  elements  of  the  Guidance  Framework  are: 


1.  Common  software  foundation  from  industry  as  the  baseline  information  system 
architecture. 

2.  Initial  command  software  functionality  for  FDS  1  to  include  suitable  items  from 
emerging  USMC  programs. 

3.  Leverage  from  industry  hardware  specifically  to  support  USMC  requirements. 

4.  Application  and  integration  software  development  only  as  deemed  essential  to 
furnish  the  required  command  software  functionality  to  be  addressed  in  each  FDS. 

5.  Provide  a  consistent,  but  evolving  system  framework  to  support  embedding 
disparate  components  and  subsystems  each  with  their  various  schedules  and 
maturities. 

6.  Institute  direct  FMF  involvement  and  direction  in  the  sequential  and  open  system 
development  environment. 

7.  Provide  an  evolving  system  platform  for  developing  interoperability  approaches 
and  resolving  issues. 

8.  Provide  system  support  for  examining  technologies  prior  to  selection  and/or 
funding  for  inclusion  in  subsequent  FDS  phases.  [Ref.  2:p  ii] 
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3.      Operational  Concept 

The  overall  operational  objective  of  FDS  1  is  to  provide  operational  personnel 
within  the  MAGTF  with  a  set  of  automated  tools  and  techniques  that  will  assist  them  in 
performing  already  established  C2  functions.  These  functions  have  already  been 
documented  and  proven  over  the  years  and  are  an  accepted  part  of  the  command  and  staff 
process.  Functionally,  FDS  1  will  put  in  place  a  system  that  will  provide  automated 
capabilities  to  commanders  and  staff  officers  in  performing  these  doctrinal  functions. 

In  support  of  these  objectives,  the  operational  concepts  employed  in  FDS  1  are 
simple.  WHAT  functions  are  performed  and  by  WHOM  will  not  be  affected  by  FDS  1, 
only  HOW  the  function  is  accomplished.  What  this  means  is  that  FDS  1  will  concentrate 
on  providing  commanders  and  staff  officers  automated  assistance  in  the  form  of 
computers,  electronic  displays,  and  digital  communications  to  perform  functions  they  are 
now  performing  manually. 

In  this  regard,  FDS  1  will  not  initially  try  to  achieve  a  wide  range  of 
"operational  functionality"  to  support  C2  personnel,  but  rather  will  focus  its  efforts  on 
putting  the  basic  support  functionality  in  place  that  will  enable  simple  operational 
functions  to  be  performed  using  automated  equipment.  The  scope  of  the  operational 
functionality  will  be  incrementally  expanded  in  future  FDS  phases  to  include  all  required 
command  and  staff  functions  deemed  appropriate  for  inclusion  in  MTACCS. 
[Ref.  2:p  1-9] 
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4.      Generalized  Objectives 

The  generalized  objectives  to  be  achieved  at  each  FDS  phase  are: 

1.  Present  to  users  a  functioning  entity,  not  just  disconnected  technologies. 

2.  Demonstrate  leverage  from  available  system  components. 

3.  Provide  increasing  experience  and  guidance  opportunities  in  the  growth  of  C2 
automated  assistance. 

4.  Provide  fieldable  system  segments  for  USMC  units. 

5.  Build  an  evolving  working  model  of  MTACCS. 

6.  Build  models  so  that  some  enduring  value  is  achieved  at  each  FDS  phase. 

7.  Institutionalize   a   development   approach   that   will    enhance    alignment   with 
requirements  and  accelerate  the  delivery  of  capability  to  the  field. 

8.  Institutionalize  a  development  approach  that  will  facilitate  integration  of  disparate 
developing  technical  subsystems.  [Ref.  2:p  iii] 

E.      THE  NEW  MARINE  CORPS  ACQUISITION  ORGANIZATION 

1.      The  Goldwater-Nichols  Reorganization  Act 

The  Goldwater-Nichols  Reorganization  Act  "requires  the  military  departments 
to  designate  a  single  office  or  entity  in  each  secretariat  to  conduct  acquisition  functions 
to  eliminate  the  parallel  or  duplicate  acquisition  offices  that  had  existed  in  both 
secretariats  and  the  services'  Chief  of  Staff  organizations".  [Ref.  26:p  2]  This  same 
guidance  was  applied  to  the  acquisition  organization  within  the  Marine  Corps. 

The  Marine  Corps  complied  with  this  act  by  creating  two  new  commands:  the 
Marine   Corps  Combat  Development  Command   (MCCDC)  and  the  Marine  Corps 
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Research,  Development,  and  Acquisition  Command  (MCRDAC).    The  Marine  Corps 

Development  and  Education  Command  (MCDEC)  was  eliminated  and  its  functions  were 

distributed  between  the  two  new  commands. 

Prior  to  this  reorganization,  acquisition  responsibilities  were  divided  among  several 
headquarters  activities.  Most  of  the  acquisition  functions  previously  conducted  by 
several  different  departments  and  divisions  in  Marine  Corps  Headquarters  were 
centralized  into  the  newly  formed  Research,  Development,  and  Acquisition 
Command.  [Ref.  9:p  54] 

2.      The  Marine  Corps  Combat  Development  Command  (MCCDC) 

MCCDC  has  the  responsibility  of  refining  requirements  that  are  identified  by 
the  Fleet  Marine  Force  (FMF).  Requirements  may  be  satisfied  through  changes  in 
doctrine,  structure,  tactics,  or  equipment.  The  Commanding  General  of  this  command 
assesses  the  FMF  requirement  in  order  to  validate  the  need  for  the  acquisition  of 
equipment.  If  new  equipment  is  needed  to  satisfy  the  requirement,  the  Warfighting 
Center  (a  component  within  MCCDC)  publishes  a  statement  of  Required  Operational 
Capability  (ROC).  The  Commanding  General  of  the  Marine  Corps  Research, 
Development,  and  Acquisition  Command  uses  this  ROC  as  the  basis  to  acquire  the  new 
equipment.    [Ref.  27:p  30] 

The  Marine  Corps  Systems  Acquisition  Management  manual  lists  specific 
responsibilities  of  the  Commanding  General  of  MCCDC.  These  responsibilities  include: 

1.  Develop  concepts,  plans,  and  doctrine. 

2.  Identify  requirements  for  changes  to  doctrine,  training,  MAGTF  force  structure, 
and  material. 

3.  Serve  as  the  MAGTF  proponent.  [Ref.  26:p  3-21] 
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The  organization  created  to  accomplish  these  tasks  is  depicted  in  Figure  19. 
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Figure  19:  MCCDC  Organizational  Diagram  [Source:  MCCDC] 

3.      The  Marine  Corps  Research,  Development,  and  Acquisition  Command 
(MCRDAC) 

The  Marine  Corps  Systems  Acquisition  Management  Manual  describes  the 

responsibilities  of  MCRDAC  as  follows: 

The  Commanding  General  of  MCRDAC  is  the  Marine  Corps  Program  Executive 
Officer  (PEO).  As  such  he  has  the  responsibility,  authority,  and  accountability  for 
all  Marine  Corps  acquisition  programs  in  accordance  with  Public  Law  98-94 
(Goldwater-Nichols  Reorganization  Act)  ...  [Ref.  26:p  3-13] 

The  Program  Executive  Officer  (PEO)  is  defined  by  the  Secretary  of  Defense, 

Dick  Cheney,  in  his  1989  report  to  the  President  on  defense  management.  In  that  report, 
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the  PEO  is  described  as  a  key  middle  manager  responsible  to  the  Service  Acquisition 
Executive  (SAE)  for  defined  and  limited  groups  of  major  programs.  The  PEO  will  have 
a  small,  separate  staff  organization  and  devote  full  time  attention  to  management  of 
assigned  programs  and  related  technical  support  resources.  [Ref.  36:p  9]  The 
streamlined  acquisition  organization  mandated  by  the  Defense  Management  Review  is 
shown  in  Figure  20.  This  streamlined  approach  was  instituted  with  the  intention  of 
establishing  clear  command  channels  for  the  acquisition  of  new  systems.  An  extract  of 
the  MCRDAC  organizational  diagram  is  shown  in  Figure  21. 
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"igure  20:   Streamlined  Acquisition  Approach  for  Major  Programs  [Source: 
Authors] 
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Ref.  26] 

The  Commanding  General  of  MCRDAC  assigns  program  managers  and  issues  their 

charters.  'The  charter  is  a  memorandum  of  understanding  between  the  program  manager 

and  his  superiors"   [Ref.  37:p  2-6].      It  details  the  precise  scope  of  the  program 

manager's  responsibility  and  authority  [Ref.  37: p  2-5]. 

The  appropriate  program  manager  takes  the  validated  ROC  and  turns  it  into  a 
reality.  The  Commanding  General  of  MCRDAC  has  the  authority  for  overall 
MTACCS  acquisition  policy,  accountability  for  acquisition  execution,  and  clear 
lines  of  command  for  program  managers...  He  has  designated  the  program  manager 
for  Marine  Air  Ground  Task  Force  (MAGTF)  Command  and  Control  as  the  focal 
point  for  MTACCS  [Ref.  27:p  30] 
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Program  managers  have  full  authority,  responsibility,  and  accountability  for  their 
programs.  They  report  directly  to  the  Program  Executive  Officer  (PEO)  for  all 
programmatic  matters,  and  are  assigned  the  full  authority  of  the  PEO  for  the 
centralized  management  of  specified  acquisition  programs.    [Ref.  26:p  3-16] 

The  Marine  Corps  Systems  Acquisition  Management  Manual  lists  thirty  five 

specific  responsibilities  of  the  Commanding  General  of  MCRDAC.  These  responsibilities 

include: 

1.  Advises  the  Commandant  on  Marine  Corps  acquisition  policy. 

2.  With  the  Commanding  General  MCCDC,  coordinates  the  implementation  of  Joint 
Service  Programs  (JSP)  and  Other  Service  Programs  (OSP). 

3.  Implements  DOD/DON/USMC  systems  acquisition  policy. 

4.  Provides  input  into  the  PPBS  for  acquisition  and  RDT&E. 

5.  Provides  guidance  to  Program  Managers  in  managing  the  business,  financial,  and 
technical  aspects  of  assigned  programs. 

6.  Represents  acquisition  programs  to  HQMC,  DON,  OSD,  and  the  Congress. 

7.  Advises  the  Commandant  at  acquisition  decision  milestones  and  coordinates  a 
number  of  review  committees. 


F.       SUMMARY 

Several  problem  areas  were  identified  by  the  Marine  Corps  during  the  MIFASS  era. 
Efforts  to  solve  those  problems  have  been  extensive.  The  main  thrust  of  these  efforts  has 
concentrated  on  a  major  reorganization  of  the  Marine  Corps  development  and  acquisition 
team  and  a  dedication  to  the  strategy  of  Evolutionary  Acquisition.  The  remainder  of  this 
thesis  examines  these  solutions  in  detail.   The  objective  is  to  develop  an  understanding 
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of  the  strengths  and  the  possible  risks  inherent  in  both  the  MTACCS  concept  and  the 
proposed  solutions  to  long  standing  problems. 
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IV.   A  FEASIBILITY  ASSESSMENT 

A.      THE  NEED  TO  QUESTION  FEASIBILITY 

Since  its  inception,  MTACCS  has  been  considered  to  be  a  bold,  farsighted  concept. 
Developing  a  fully  operational,  effective  command  and  control  system  of  this  scope  will 
pose  a  major  challenge  to  the  Marine  Corps.  The  risk  of  failure  is  significant.  While 
supporters  of  the  MTACCS  concept  are  optimistic,  there  is  considerable  precedent  to 
cause  concerns;  concern  that  the  system  may  not  be  compatible  with  current  doctrine; 
concern  that  the  objectives  may  not  even  be  technically  possible  at  any  reasonable  cost. 
There  must  be,  at  the  very  outset,  an  assessment  of  the  feasibility  of  this  project. 

For  the  purpose  of  this  thesis,  feasibility  is  defined  as  the  satisfaction  of  the 
following  general  criteria.   To  be  feasible,  MTACCS  must  be: 

1.  Compatible  with  current  doctrine  and  established  procedures. 

2.  Technically  possible. 

3.  Limited  in  complexity,  not  the  most  sophisticated  system  imaginable. 

4.  Procured  with  an  effective  acquisition  strategy. 

While  these  criteria  have  been  chosen  based  on  subjective  determination,  there  is  little 
doubt  that  they  represent  a  collection  of  common  sense  factors  vital  to  the  success  of  the 
MTACCS  project. 
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Many  risk  factors  have  already  been  identified  and  addressed  within  the  draft 
MTACCS  Master  Acquisition  Plan  (MAP).  Some  risk  factors,  however,  have  not  been 
presented.  Others  have  been  acknowledged,  but  not  yet  thoroughly  explored.  The  effort 
of  this  chapter  will  be  on  developing  a  complete  understanding  of  the  risks  involved  in 
developing  this  command  and  control  system  in  order  to  evaluate  the  likelihood  of 
success. 

Much  of  the  question  of  feasibility  centers  on  risk  analysis.  Defining  the  idea  of 
"risk"  is  crucial  to  this  assessment.  Several  factors  have  been  identified  to  qualitatively 
measure  risk: 

1.  To  what  degree  is  the  anticipated  technology  available  now? 

2.  What  is  the  extent  of  user  advocacy? 

3.  How  well  are  the  tasks  involved  defined  and  understood? 

4.  What  is  the  stability  of  the  mission  and  the  environment? 

5.  What  is  the  expected  length  of  time  to  develop  needed  technologies? 

6.  Are  the  procurement  strategies  tested?   Appropriate? 

While  this  list  is  not  exhaustive,  these  factors  will  provide  some  of  the  basis  for 
determining  how  much  risk  is  involved  in  meeting  each  of  the  feasibility  criteria. 
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B.       THE  FEASIBILITY  CRITERIA 

1.  MTACCS  must  be  Compatible  with  Current  Doctrine  and  Established 
Procedures 

The  warfighting  doctrine  of  the  United  States  Marine  Corps  provides  the 

authoritative  basis  for  the  conduct  of  war  by  Marine  forces.  While  authoritative,  doctrine 

is  not  prescriptive  [Ref.  38:p  44].     In  the  broad  sense,  doctrine  is  the  foundation 

for  the  development  of  organizations  and  procedures.  The  command  and  control  system 

includes  these  organizations  and  procedures  as  well  as  the  communications  and  computers 

of  automated  decision  support  systems.     It  has  been  decided  from  the  outset  of  the 

program  that  the  MTACCS  effort  will  not  change  current  MAGTF  staff  and  unit 

organizations  [Ref.  32:p  3].    The  doctrine  that  is  the  basis  of  the  organization  must  be 

complimented     by     the     concept     that     defines     the     decision     support     systems. 

It  is  a  frequently  cited  axiom  of  systems  analysis  that  information  models  the 
organization.  An  information  system  should  model  the  structure  of  the 
organization.  [Ref.  39:p  57] 

2.  MTACCS  must  be  Technically  Possible 

There  is  no  doubt  that  the  technical  integration  of  numerous  disparate 
automated  systems  across  the  entire  spectrum  of  the  battlefield  will  be  a  complex 
problem.  There  are  many  questions  that  must  be  answered  as  development  of  the 
MTACCS  concept  proceeds.  The  MTACCS  Operational  Concept  implies  several 
technical  requirements.   Among  these  are: 

1.     Multi-level  security. 
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2.  Extensive  data  communications. 

3.  Real  time  or  near  real  time  processing  capability. 

4.  Challenging  software  development. 

The  technical  feasibility  of  these  requirements  is  difficult  to  assess.  There  are  implied 
requirements  that  have  not  yet  been  completely  defined.  Still,  a  technical  assessment  can 
be  made  to  develop  an  understanding  of  the  general  level  of  difficulty  expected  in 
achieving  the  goals  of  MTACCS. 

3.      MTACCS  must  be  Limited  in  Complexity 

It  was  pointed  out  in  Chapter  II  that  a  common  weakness  of  many  defense 
programs  is  the  desire  to  obtain  the  most  sophisticated  system  available,  regardless  of  cost 
and  schedule  delays. 

Robert  R.  Everett17  has  written: 

There  is  a  normal  human  tendency  to  want  more  than  is  provided.  We  have,  in 
fact,  enormously  greater  technical  capability  than  we  had  a  few  years  ago  but  we 
cannot  do  everything,  certainly  not  for  a  reasonable  sum  of  money...  If  some 
elements  of  the  system  are  over  specified,  over  complex,  and  over  expensive,  some 
other  elements  may  have  to  go  without  and  the  performance  of  the  whole  system 
may  be  limited  by  the  weaker  parts...  A  considerable  amount  of  thoughtful  work  is 
now  going  on  into  C3  evaluation  to  help  alleviate  this  problem,  but  it  is  one  of  great 
difficulty.  [Ref.  40] 

To  avoid  this  pitfall,  MTACCS  should  be  limited  in  complexity.  Here,  limited 

is  defined  as  attempting  to  develop  a  level  of  sophistication  that  is  sufficient  to  achieve 

desired  goals  yet  obtainable  within  time  constraints  at  reasonable  effort.    Admittedly, 


17         Robert  R.  Everett  is  a  past  president  of  the  MITRE  Corporation. 
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modifiers  such  as  "sufficient"  and  "reasonable"  are  open  to  interpretation.  The  goal  is  not 
to  establish  rigid  definitions,  but  rather  to  convey  the  idea  that  the  problem  must  be 
approached  in  a  practical  manner,  mindful  of  the  time  critical  need  for  this  system  and 
of  the  fiscal  austerity  that  looms  in  the  future  of  MTACCS. 

4.      MTACCS  must  be  Procured  with  an  Effective  Acquisition  Strategy 

The  acquisition  strategy  determines  the  success  or  failure  of  a  system.  An 
effective  strategy  is  one  that  provides  an  organized  and  consistent  approach  to  meeting 
the  program  objectives  within  known  constraints  through  an  overall  plan. 

C.  ASSESSMENT  OF  MTACCS  COMPATIBILITY  WITH  CURRENT 
DOCTRINE 

1.      The  Importance  of  Compatibility 

The  MTACCS  Operational  Concept  Document  states  "the  MTACCS  concept 
supports  and  is  consistent  with  service  plans  and  doctrine"  [Ref.  1],  There  has,  however, 
been  no  formal  assessment  found  in  the  numerous  MTACCS  documents  (many  in  draft) 
that  addresses  the  subject  of  compatibility  with  current  doctrine  and  established 
procedures.  The  compatibility  factor  can  be  a  significant  contributor  to  the  downfall  of 
any  program.  It  was  clear  that  the  MIFASS  program  was  crippled  by  its  incompatibility 
with  "accepted"  doctrine  and  procedures.  It  was  intended  to  operate  within  a  doctrine  of 
centralization  that  was  characterized  by  the  Fire  and  Air  Support  Center  (FASC)  concept. 
When  decisions  were  made  to  remain  primarily  with  decentralized  procedures  or  use  a 
combination  of  both,  MIFASS  was  no  longer  entirely  compatible.    Major  rework  was 
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necessary  to  try  and  force  MIFASS  to  support  a  doctrine,  an  organization,  and  a  set  of 
procedures  that  it  was  not  initially  intended  to  support.  The  MTACCS  concept,  its  goals, 
and  its  objectives  must  be  compatible  with  the  ideas  of  warfighting  as  practiced  in  the 
Marine  Corps  today. 

2.      Warfighting  Doctrine 

a.  Doctrine 

Fleet  Marine  Force  Manual  1,  Warfighting,  provides  the  authoritative 
basis  for  how  Marines  fight  [Ref.  38:p  i].  The  manual  establishes  many  of  the  guiding 
principles  that  Marines  must  use  to  achieve  success  in  the  conduct  of  war.  Several  key 
principles  that  are  established  by  the  manual  will  be  discussed  to  provide  a  foundation  in 
Marine  Corps  doctrine. 

b.  Maneuver  Warfare 

The  Marine  Corps  concept  for  winning  on  the  modern  battlefield  is  a 
warfighting  doctrine  based  on  rapid,  flexible,  and  opportunistic  maneuver.  It  is  through 
maneuver  in  both  time  and  space,  that  a  force  can  achieve  decisive  superiority  at  the 
necessary  time  and  place.  [Ref.  38:p  58]  An  emphasis  on  maneuver  warfare  implies  a 
need  for  forces  that  are  light,  fast,  and  efficient 

c.  Decentralization  off  Command 

The  doctrinal  issue  of  centralization  versus  decentralization  was  a  pivotal 
factor  on  the  failure  of  the  MIFASS  program.  The  support  for  decentralized  control  was 
stronger  then  and  remains  pervasive.   FMFM  1  boldly  asserts: 
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First  and  foremost,  in  order  to  generate  the  tempo  of  operations  we  desire  and  to 
best  cope  with  the  uncertainty,  disorder,  and  fluidity  of  combat,  command  must  be 
decentralized.  That  is,  subordinate  commanders  must  make  decisions  on  their  own 
initiative,  based  on  their  understanding  of  their  senior's  intent...  [Ref.  38:p  62] 

d.  Implicit  Communications 

Marine  Corps  doctrine  promotes  a  reliance  on  the  "human  element"  of 

command.     Marine  Corps  philosophy  must  not  only  accommodate,  but  must  exploit 

human  traits  such  as  boldness,  initiative,  personality,  strength  of  will,  and  imagination. 

[Ref.  38:p  62]   Along  with  this  basic  belief  in  the  importance  of  the  human  element,  the 

Marine  Corps  stresses  the  importance  of  "implicit  communication". 

Implicit  communication  -  to  communicate  through  mutual  understanding,  using  a 
minimum  of  key,  well  understood  phrases  or  even  anticipating  each  others  thoughts 
-  is  a  faster,  more  effective  way  to  communicate  than  through  the  use  of  detailed, 
explicit  instructions.  [Ref.  38:p  63] 

A   practical    implication    of  this   philosophy   is   that   Marines   should 

communicate  orally  when  possible,  because  we  communicate  in  how  we  talk;  in  our 

inflections  and  our  tone  of  voice.  [Ref.  38:p  63] 

e.  Decision  Making 

The  making  of  competent  and  timely  decisions  is  recognized  as  essential 

to  victory  in  war. 

Whoever  can  make  and  implement  his  decisions  consistently  faster  gains  a 
tremendous,  often  decisive  advantage.  Decision  making  thus  becomes  essential  to 
generating  tempo.  We  should  spare  no  effort  to  accelerate  that  decision  making 
capability.  [Ref.  38:p  69] 
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/.       Focus  of  Effort 

More  than  300  years  ago,  Antoine-Henri  Jomini  proposed  the  idea  of  a 

"decisive  point"  of  vulnerability.  Victory  could  be  achieved  only  by  massing  one's  forces 

against  this  decisive  point.  [Ref.  41]     The  idea  of  a  "Focus  of  Effort"  is  a  similar 

philosophy. 

Of  all  the  efforts  going  on  within  our  command,  we  recognize  the  focus  of  effort 
as  being  the  most  critical  to  success.  All  other  efforts  must  support  it. 
[Ref.  38:p  73] 

An  important  implication  of  this  principle  is  the  need  for  coordination  and 

integration  of  forces  to  maintain  a  focus. 

g.      Combined  Arms 

The  Marine  Corps  has  long  advocated  the  integration  of  combined  arms 

in  the  conduct  of  war. 

In  order  to  maximize  combat  power,  we  must  use  all  the  available  resources  to  best 
advantage.  To  do  so,  the  Marine  Corps  must  follow  a  doctrine  of  combined  arms. 
Combined  arms  is  the  integration  of  arms  in  such  a  way,  that  in  order  to  counteract 
one,  the  enemy  must  make  himself  more  vulnerable  to  the  other.  [Ref.  38:p  75] 

3.      MTACCS  Objectives  that  are  Pertinent  to  Compatibility 

Several  important  objectives  of  the  MTACCS  concept  impact  on  its 
compatibility  with  current  doctrine.  The  MTACCS  operational  concept  document  outlines 
the  following  general  objectives  that  are  pertinent  to  compatibility: 

1.  MTACCS  must  be  as  expeditionary  as  the  force  it  supports. 

2.  MTACCS  must  permit  commanders  to  lead  from  where  they  are  most  needed. 
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3.  MTACCS  should  not  impede  mobility. 

4.  The  communications  architecture  must  evolve  from  a  network  of  functionally 
dedicated  voice  channels  into  a  system  of  digital  information  pipelines. 

5.  MTACCS  will  provide  a  common  user,  centrally  managed  database. 


The  first  three  of  these  listed  objectives  are  entirely  compatible  with  the 
doctrine  that  has  been  described.  They  demonstrate  a  recognition  that  the  Marine  Corps 
will  operate  in  an  expeditionary  environment;  an  environment  that  mandates  the  capability 
to  deploy  rapidly  and  operate  under  austere  conditions.  The  ideas  of  evolving 
communications  and  a  centrally  managed  database,  however,  require  investigation.  Both 
imply  the  possibility  of  conflict  with  current  doctrine. 

4.      Compatibility  Assessment 

a.      An  Evolving  Communications  Architecture 

Historically,  there  has  been  considerable  difficulty  establishing  what 
information  should  be  data  and  what  should  remain  voice  in  a  C2  system.  [Ref.  30:p  228]. 
While  current  Marine  Corps  doctrine  emphasizes  voice  transmissions,  face-to-face 
interaction,  and  "implicit  communications",  the  objective  of  MTACCS  appears  to  be 
aimed  at  significantly  reducing  voice  traffic.  This  conflict  can  have  important 
implications.  A  conflict  with  doctrine  can  cause  division  within  the  Marine  Corps  and 
a  loss  of  user  advocacy. 

The  point  is  not  trivial.  In  his  book  Command  in  War,  Martin 
Van  Creveld  emphasizes  the  importance  of  informal  communications: 
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...  it  is  vital  that  the  formal  communication  system  be  supplemented  by  an  informal 
one  that  acts,  so  to  speak,  as  lubricating  oil.  In  any  large  organization,  the  virtues 
of  formal  communications  systems  -  standardization,  brevity,  and  precision  -  cannot 
be  denied;  those  very  virtues,  however,  also  make  such  a  system  more  subject  to 
interruption  and  less  flexible  as  a  vehicle  for  original  ideas...  The  danger  that  formal 
communications  reduce  command,  and  indeed  thought  itself,  to  trivia  is  a  real  one 
indeed.  It  must  be  guarded  against  by  a  design  that  deliberately  leaves  room  for 
face-to-face,  unstructured  interaction...  such  exchanges  represent  the  best  way  both 
of  cutting  down  the  total  amount  of  communications  that  has  to  take  place  and  of 
improving  the  quality  of  that  communication.    [Ref.  42:p  273] 

b.  A  Centrally  Managed  Database 

The  centralization  versus  decentralization  conflict  was  a  contributor  to  the 
downfall  of  MIFASS.  Since  then,  the  Commandant  has  reemphasized  the  importance  of 
the  decentralization  of  command.  A  centrally  managed  database  implies  movement  in  a 
conflicting  direction.  It  is  true  that  a  centrally  managed  database  that  is  sufficiently 
replicated  and  distributed  can  support  decentralized  decision  making.  A  complete 
assessment  of  this  idea  therefore,  cannot  be  made.  The  particulars  of  the  design  and 
implementation  of  the  centrally  managed  database  have  not  yet  been  developed.  The 
level  and  purpose  of  centralization  continue  to  be  an  important  concern  in  the  future  of 
MTACCS. 

c.  Conclusions  on  Compatibility 

There  continues  to  be  considerable  potential  for  doctrinal  incompatibility 
within  the  MTACCS  concept  as  currently  stated.  This  compatibility  problem  can  be 
averted  but  must  be  given  appropriate  attention  in  order  to  avoid  a  result  similar  to 
MIFASS. 


94 


The  Field  Development  System  concept  document  implies  that  doctrinal 
conflicts  will  be  avoided  since  MTACCS  will  only  affect  how  a  task  is  performed  and 
not  by_  whom.  This  idea  can  help  to  avert  the  tendency  towards  centralization.  If  no 
changes  are  made  in  who  makes  the  decisions,  the  system  will  tend  to  maintain  a 
decentralized  structure  that  reflects  the  current  organization.  Doctrine,  however,  also 
implies  how  something  will  be  done,  as  has  been  shown.  An  emphasis  on  "implicit 
communications"  implies  voice  transmissions,  for  example. 

The    centralization    issue    is    especially    sensitive.       The    degree    of 

centralization  must  be  explicitly  defined  and  accepted  early  in  the  program.    Robert  R. 

Everett  has  written: 

The  potential  for  centralization  that  resides  in  modern  C3  technology  creates  great 
tension  in  the  military  structure.  The  C3  designer  says  "Let's  provide  the  capability 
and  argue  about  who  does  what  later",  but  the  local  commander  knows  better.  [Ref. 
40] 

D.      ASSESSMENT  OF  MTACCS  TECHNICAL  FEASIBILITY 

1.      The  Need  to  Work  Within  Technical  Reality 

Obviously,  developers  and  contractors  begin  each  new  project  with  the  belief 
that  they  can  accomplish  the  task.  They  are  optimistic.  They  have  assessed  the  technical 
risks  and  judged  them  to  be  within  reason.  But  this  "judgement"  is  not  infallible.  It  was 
shown  in  Chapter  II  that  Norden  Systems  dramatically  underestimated  the  volume  and 
complexity  of  software  necessary  for  MIFASS.  This  underestimation  led  them  to  believe 
they  could  build  a  system  light  enough  to  meet  Marine  Corps  needs.  When  software 
requirements  escalated,  the  hardware  technology  of  the  day  was  stretched  beyond  its 
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capacity.  The  hardware  increased  in  size  to  handle  the  new  processing  requirements. 
Eventually,  the  sheer  size  and  weight  of  the  equipment  became  intolerable.  It  appears 
that  processing  fire  and  air  support  coordination  in  a  box  light  enough  and  rugged  enough 
for  Marines  was  not  possible  given  the  technology  limitations  of  that  day. 

Several  technical  risk  issues  have  been  identified  by  program  coordinators  and 
contractors.  The  possibility  of  problems  in  the  areas  of  multi-level  security  and 
communications  capacity  have  been  anticipated.  The  possibility  of  continued  software 
development  problems  was  not  specifically  addressed  in  the  documents  currently 
available. 

It  is  imperative  that  the  MTACCS  project  assess  the  technical  risk  of 
implementing  its  goals.  To  that  end,  this  chapter  addresses  three  key  technical  questions 
that  are  derived  from  implied  requirements: 

1 .  Can  current  and  projected  communications  systems  meet  the  anticipated  level  of 
data  communications? 

2.  Will  adequate  multi-level  security  be  achievable? 

3.  What  assurances  are  there  that  software  development  will  succeed  this  time? 

The  ability  to  answer  these  questions  is  restricted  for  several  reasons.  Many 
of  the  requirements,  for  example,  have  not  yet  been  defined.  Valuable  insight,  however, 
can  be  developed  from  a  qualitative  calculation  of  the  technical  feasibility  of  meeting 
implied  requirements. 
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2.      Capacity  of  the  Communications  System 

In  October  of  1988,  the  Naval  Research  Advisory  Committee  published  a 

report  on  intra/interoperability  of  Marine  Corps  command  and  control  systems.    That 

report  stated  in  its  executive  summary: 

...  it  is  unlikely  that  existing  or  planned  tactical  communications  systems  will  have 
adequate  capacity,  connectivity,  robustness,  and  multi-level  security  to  support 
future  battlefield  information  systems.  [Ref.  43:p  3] 

They  found  that  the  Marine  Corps  had  not  done  an  up-to-date  analysis  to 
define  in  detail  the  communications  requirements  to  support  the  MTACCS  component 
systems  [Ref.  43:p  33].  It  appears  that  there  continues  to  be  a  lack  of  detailed 
information  in  this  area.  The  draft  MTACCS  Master  Acquisition  Plan  states:  "No  data 
has  been  developed  to  bound  the  communications  requirement  for  MTACCS.  The 
evolutionary  developing  MTACCS  will  be  a  source  of  feedback  requirements  for  the 
communications  system  for  the  procurement  of  greater  digital  handling  capacity." 
[Ref.  32:p  3] 

The  data  requirements  of  MTACCS  will,  in  all  likelihood,  quickly  overwhelm 
the  capacity  of  current  communications  systems.  The  Marine  Corps  expects  this  to 
happen.  Specifics  of  the  Marine  Corps'  plan  to  counter  this  problem  are  not  entirely 
clear.  One  can  speculate  that  the  Corps  is  watching  closely  the  progress  of  the  Army  in 
addressing  this  same  problem.  The  Army's  Tactical  Command  and  Control  System 
(ATCCS)  will  use  some  of  the  same  tactical  communications  equipment  that  the  Marine 
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Corps  will  use18.  ATCCS  will  more  than  likely  have  similar  data  flow  requirements. 
The  army  plan  will  include  deployment  of  packet  switch  appliques  to  circuit  switched 
bearer  systems  to  extend  their  communications  capacity.  [Ref.  44:p  181] 

An  increase  in  the  capacity  of  switching  equipment  alone,  however,  may  not 
be  sufficient.  Much  of  the  data  traffic  will  continue  to  travel  over  single  channel  radio 
circuits,  not  a  switched  backbone.  A  switched  backbone  lacks  the  flexibility  of  single 
channel  radio  and  it  cannot  completely  supplant  radio  circuits. 

3.      Multi-level  Security 

The  integration  of  the  MTACCS  component  subsystems  will  require  a 
capability  for  multi-level  security.  An  operator  utilizing  the  TCO  system,  for  example, 
will  have  the  capability  of  accessing  several  databases  with  varying  levels  of  security 
classifications. 

As  noted  earlier,  however,  there  is  little  confidence  in  the  evaluation 
community  that  the  systems  available  or  in  development  will  have  a  secure,  trusted,  multi- 
level capability.  With  the  leaps  and  bounds  technology  continues  to  make  at  an 
accelerated  pace,  the  era  of  secure  trusted  systems  is  not  far  away.  William  Barker  stated 
in  Signal  magazine  that: 

All  the  necessary  trusted  computer  and  cryptographic  components  exist,  what 
remains  is  the  secure  integration  of  the  trusted  cryptographic  control  functions  into 
workstation  hardware  and  evaluation  of  the  resulting  information  security 
workstations.  [Ref.  45 :p  59] 


Both  the  Army  and  the  Marine  Corps  are  fielding  SINCGARS  equipment,  for 
example. 
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There  is  currently  a  commercial  device  in  development  that  has  demonstrated 
the  ability  to  allow  classified  and  unclassified  users  to  share  the  same  network  without 
compromising  classified  information.  This  system  works  on  the  basis  of  encrypting  the 
classified  information,  thereby  rendering  it  unintelligible  to  unauthorized  users.  This 
means  that  many  types  and  classifications  of  users  can  work  on  the  same  network  without 
compromising  classified  information.  This  system,  developed  by  Xerox,  is  reported  to 
be  able  to  turn  any  computer  network  into  a  network  capable  of  handling  classified  data. 
[Ref.  46:p  92]  Although  this  appears  promising,  the  system  throughput,  after 
merging  cryptographic  functions  with  network  level  protocol  functions,  is  still  too  slow 
for  many  user  requirements  and  applications  [Ref.  45:p  56]. 

There  does  not  currently  appear  to  be  system  capable  of  meeting  the  MTACCS 
requirements  for  information  security  if  sensitive  intelligence  databases  are  to  be  an 
integrable  part.  The  outlook  is  good  for  the  future,  but  user  confidence  in  secure,  trusted 
systems  must  be  cultivated  in  order  for  MTACCS  to  successfully  integrate  with  the 
intelligence  community. 

4.      Software  Development 

a.      The  Increasing  Importance  of  Software 

Software  has  become  the  dominant  factor  in  many  of  today's  military 
systems.  This  is  especially  true  in  command  and  control  systems  which  tend  to  be  very 
software  intensive.  An  estimated  80-90%  of  the  development  costs  of  command  and 
control  systems  can  be  attributed  to  software.  [Ref.  47:p  92] 


99 


In  the  1960's,  CIS  managers  went  by  a  rule  of  thumb  that  put  the  cost  of  computer 
hardware  at  about  seven  or  eight  times  the  cost  of  software.  Since  that  time, 
software  costs  have  risen  steadily. ..during  this  same  period,  hardware  costs  have 
come  down  rapidly. ..thus  the  ratio  between  the  cost  of  hardware  and  the  cost  of 
software  has  shifted  dramatically.  Today,  software  costs  are  estimated  to  be  about 
ten  times  greater  than  hardware  costs.  [Ref.  39:p  33-34] 

Like  most  command  and  control  systems,  MTACCS  will  be  software 

intensive.  The  development  of  MTACCS  software  will  play  a  major  role  in  determining 

the  success  of  the  program. 

b.      The  Crisis  in  Software  Development 

While  the  capability  of  computer  hardware  has  risen  dramatically  over 
the  last  decade,  the  capability  of  software  has  not  kept  pace.  Major  General  Billy  M. 
Thomas19  was  recently  quoted  in  Army  magazine  as  saying  "the  entire  software  industry 
is  at  the  Model  T  Ford  stage  right  now."  [Ref.  48:p  36]  Clearly,  there  is  a  low 
expectation  of  the  current  state  of  the  software  development  art. 

The  excessive  schedule  delays  and  cost  overruns  in  software  development 
projects  throughout  the  Department  of  Defense  have  reached  crisis  proportions.  "Experts 
are  now  saying  that  the  chief  military  software  problem  may  soon  be  that  DOD  cannot 
get  enough  of  it  -  period."  [Ref.  49:p  27]  This  problem  affects  everybody. 
General  James  S.  Cassity  Jr.20,  USAF,  wrote  in  1988  "..  ask  any  program  manager  what 


Major  General  Thomas  was  the  Commanding  General  of  the  U.S.  Army 
Communications-Electronics  Command  at  the  time  of  the  Army  magazine  interview. 


20 


Commander,  Air  Force  Communications  Command  in  1988. 
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his  or  her  number  one  nightmare  is  today  and  the  answer  is  software;  it  is  the  cause  of 

most  program  delays."  [Ref.  50: p  39] 

This  crisis  is  not  strictly  a  problem  for  the  contractors  to  solve  alone. 

Developers  as  well  must  take  action  to  reduce  the  risk  of  software  development  failure. 

The  report  from  a  major  software  conference  hosted  by  the  Army's  Communications 

Electronics  Command  (CECOM)  in  1989  emphasized  this  point: 

Most  of  the  current  problems  in  software  development  are  not  technical  in  nature. 
They  are  management  problems.. .unfortunately,  little  attention  has  been  paid  to  the 
software  development  process,  which  is  often  poorly  controlled. 
[Ref.  51:p5] 

In  the  development  of  MTACCS  software,  "management"  is  largely    a 

responsibility  of  Marines;  members  of  the  three  commands  that  together  serve  as  the 

systems  engineering  management  team.  Marines  must  devote  their  fullest  attention  to  the 

mitigation  of  software  development  problems. 

c.      A  History  of  Software  Development  Problems 

The  MIFASS  program  was  plagued  with  software  problems,  but  MIFASS 
was  not  alone.  Software  problems  are  pervasive  throughout  the  Department  of  Defense. 
General  Bernard  Randolph21,  USAF,  was  quoted  in  Military  Forum  as  saying  "on 
software  schedules,  we've  got  a  perfect  record;  we  haven't  met  one  yet."  [Ref.  49:p  29] 
Historically,  software  development  in  the  military  has  been  poor. 


Chief  of  Air  Force  Systems  Command  at  the  time. 
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d.      How  to  Avoid  the  Software  Development  Dilemma 

Avoiding  the  software  dilemma  is  not  easy.  Experts  in  the  field  of 
software  development  are  optimistic,  but  they  also  realize  that  major  modification  of  the 
software  development  process  is  necessary.  Many  of  these  experts  have  recommended 
methods  of  improving  the  chances  of  successful  development.  Those  recommendations 
are  outlined  here:  [Ref.  51  :p  8] 

(1 )  Buy  rather  than  build.   Barry  W.  Boehm22  has  written: 

Clearly,  if  you  want  to  improve  your  organization's  software  price-performance 
ratio,  one  major  principle  is  "Don't  build  custom  software  where  mass  produced 
software  will  satisfy  your  needs."  [Ref.  52:p  43] 

(2)  Build  simpler  products.    It  is  an  increasingly  popular  opinion  that 

the  only  way  to  avoid  excessive  risk  in  the  development  of  software  is  to  settle  for  a 

modest  software  capability  and  see  much  of  the  capability  of  the  hardware  go  unrealized. 

This  opinion  was  colorfully  presented  in  the  SoftCon  '89  report  published  by  CECOM: 

We  also  need  some  appetite  suppressants  for  the  users.  If  you  have  to  go  to  the 
hospital,  it  is  better  to  have  a  Ford  on  the  road  than  a  Mercedes-Benz  half  built  in 
the  garage.  [Ref.  51:p  5] 

The  growing  software  shortage  means  that  the  end  user  will  have  to  moderate 
his  demand  for  unrealized  performance  which  has  so  driven  complexity,  experts 
contend.  It  will  also  mean  buying  more  off-the-shelf  software  available  in  the 
commercial  market.  Traditionally,  the  services  have  failed  on  both  accounts. 
[Ref.  49:p31] 


Barry  W.  Boehm  was  the  chief  scientist  in  the  Office  of  Technology  at  the 
TRW  Defense  Systems  Group  when  this  article  was  published  in  1987. 
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(3 )  Use  prototypes.  Valuable  experience  and  insight  to  the  users  actual 
needs,  and  not  perceived  requirements,  can  be  gained  from  the  use  of  prototypes.  A 
software  prototype  should  be  considered  just  that;  a  prototype.  A  tool  to  help  identify 
requirements  and  to  ascertain  feasibility.  The  prototype  demonstrates  what  technology 
is  actually  capable  of  and  how  the  objective  system  should  behave  [Ref.  51:p  5].  The 
prototype  provides  the  base  for  the  operational  solution,  but  rarely  is  the  prototype 
sufficient  in  itself  to  be  considered  the  best  solution,  both  in  operational  capability  and 
life  cycle  costs,  to  the  operational  requirement  [Ref.  51  :p  111]. 

(4)  Involve  the  user  in  the  requirements  process.  This  is  an  idea  that 
has  been  repeated  continuously  throughout  this  thesis  and  reference  material  as  well.  This 
is  the  only  way  to  ensure  that  the  system  fielded  is  actually  what  the  user  wants  and 
needs.  The  user  does  not  have  to  be  software  literate  in  terms  of  design  and  engineering, 
but  must  be  thoroughly  proficient  in  his  military  occupation.  Only  by  being  thoroughly 
proficient  can  he  ensure  that  the  system  will  actually  serve  a  useful  role  in  the  military 
environment. 

Another  idea  that  has  been  repeated  also  applies:  the  use  of 
incremental  development.  Incremental  development  coupled  with  frequent,  competent 
user  feedback  has  proven  to  be  the  most  effective  technique  for  fielding  useful  systems. 
[Ref.  51:p4] 

(5)  Plan  for  Controlled  Technology  Insertion.  Most  current  software 
development  problems  are  not  technical,  but  are  management  related  problems.    Not 
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enough  attention  has  been  paid  to  the  software  development  process.  Rather,  the 
concentration  has  been  on  exhaustive  testing  of  a  particular  product.  [Ref.  51  :p  5] 
Coordinating  the  upgrading  of  software  incorporating  new  technology  should  be  planned 
in  advance  to  ensure  the  effectiveness  of  the  system  as  a  whole  is  increased.  It  is 
possible  to  add  new  technology  into  a  system  which  greatly  enhances  the  performance  of 
a  particular  part,  but  the  overall  performance  of  the  system  is  degraded. 

(6)  Promote  the  use  of  standards.  Standards  improve  our  capability  to 
communicate  without  hampering  innovation.  Standard  interfaces  and  languages  allow 
developers  to  concentrate  on  the  program  itself.  Time  and  money  is  saved  by  not  having 
to  redevelop  interfaces  or  work  around  software  incompatibilities.  [Ref.  51  :p  104] 

e.      Current  MTACCS  Software  Development  Methodology 

Pacific  Northwest  Laboratories  has  been  contracted  as  the  system  engineer 
and  integrator  for  MTACCS.  Their  draft  recommendations  for  the  software  components 
of  MTACCS  were  based  on  several  general  criteria: 


1.  Commonality.  The  recommended  architecture  should  capitalize  on  developments 
made  by  the  Army's  CASS23  working  groups  and  by  Marine  Corps  C2  programs. 

2.  Interoperability.    Recommendations  should  focus  on  enhancing  communications 
between  C2  programs. 

3.  Non-Proprietary.   No  recommendation  will  be  vendor  specific. 

4.  Use  of  Non-Developmental-Items.    No  recommendations  will  rely  on  a  product 
that  has  not  been  developed. 


23 


Common  Army  Tactical  Command  and  Control  System  Support  Software. 
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5.  Availability /Maintainability.  Recommended  components  should  be  easily  available 
from  a  number  of  different  sources  and  should  be  well  supported  and  maintained, 

6.  Graceful    Degradation.      The    overall    architecture    should    provide    sufficient 
redundancy  so  that  loss  of  part  of  the  system  does  not  degrade  the  entire  system. 

7.  Supportability  of  Future  Developments.    Recommendations  should  not  prevent 
incorporation  of  new  equipment  or  ideas  into  the  system. 

8.  Recommendations     should     follow     industry     standards     wherever     possible. 
[Ref.  34:p  3.4] 


/.       Assessment  of  Software  Development 

It  is  clear  that  both  the  Marine  Corps  and  its  contractors  are  intent  on 
implementing  all  of  the  generally  accepted  methods  for  averting  disastrous  problems  in 
software  development.  Of  the  six  recommendations  listed  earlier  for  avoiding  software 
problems,  Pacific  Northwest  Laboratories  has  specifically  endorsed  three  as  criteria  for 
determining  their  software  recommendations.  The  remaining  three  are  expected  to  be 
implemented  through  the  Field  Development  System  (FDS).   They  are: 

1.  Build  simpler  products. 

2.  Use  prototypes. 

3.  Involve  the  user  in  the  requirements  process. 

These  ideas,  however,  are  still  in  their  infancy.  FDS-1  has  not  yet  been 
demonstrated.  Marine  Corps'  intentions  for  software  development  are  promising,  but  a 
more  detailed  assessment  will  not  be  possible  until  the  system  matures. 
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5.      Conclusions  on  Technical  Feasibility 

a.  Capacity  of  the  Communications  System 

There  is  a  generally  accepted  expectation  that  the  data  requirements  of 
MTACCS  will  exceed  the  capability  of  current  equipment.  Clearly,  enhancements  are 
required  to  boost  the  capability  of  the  communications  equipment.  Developing  these 
enhancements  will  take  time,  but  there  are  at  least  several  reasons  for  optimism: 

1.  The  problem  is  already  generally  accepted. 

2.  The  Army  does  have  a  plan  to  develop  packet  switch  appliques  to  enhance 
communications  capability. 

3.  MTACCS  will  be  developed  incrementally  and  is  not  expected  to  immediately 
overwhelm  the  communications  system. 

b.  Multi-level  Security 

Although  there  is  not  a  capability  currently  available,  there  has  been  a  lot 
of  promising  progress  in  the  commercial  market  place.  At  the  rate  of  present 
development  and  market  demand  by  the  civilian  sector,  a  multi-level  security  capability 
should  be  available  within  the  next  few  phases  of  the  MTACCS  Field  Development 
System. 

c.  Software  Development 

While  software  development  continues  to  be  an  exceedingly  difficult  task 
throughout  DOD,  the  initial  outlook  for  MTACCS  is  favorable.  MTACCS  software 
development  is  still  in  its  infancy,  but  the  development  procedures  and  criteria  that  have 
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been  established  are  in  complete  agreement  with  software  experts  throughout  both  DOD 
and  industry.  If  these  procedures  are  maintained  and  adhered  to,  a  successful  software 
development  project  is  likely. 

E.  LEVEL  OF  COMPLEXITY  ASSESSMENT 

It  is  explicitly  stated  in  the  MTACCS  Operational  Concept  that: 

Systems  and/or  equipment  complexity  and  operational  sophistication  shall  be  kept 
to  a  minimum  consistent  with  providing  the  required  operational  capability  to  the 
MAGTF.    [Ref.  l:p  B-l] 

While  MTACCS  is  intrinsically  complex,  the  current  development  approach  does 
tend  to  limit  the  complexity  of  each  FDS  phase.  A  small,  limited  set  of  goals  will  be 
established  for  the  first  increment  of  MTACCS.  Only  those  goals  will  be  pursued. 
Greater  sophistication  will  be  left  to  follow  on  increments. 

Throughout  all  of  the  FDS  and  MTACCS  documents,  there  is  a  common  theme: 
MTACCS  must  not  and  will  not  attempt  to  tackle  too  much  in  any  one  increment.  There 
is  caution  expressed  at  every  turn.  The  emphasis  on  the  "build  a  little,  test  a  little,  field 
a  little"  approach  is  a  reassuring  indication  that  the  project  will  proceed  with  complexity 
held  within  practical  limits. 

F.  ASSESSMENT  OF  ACQUISITION  STRATEGY 

1.      The  Impact  of  Acquisition  Strategy 

Poor  acquisition  strategy  decisions  can  have  serious  adverse  effects  on  any 
program.   In  retrospect,  it  was  a  poor  strategy  of  the  MEFASS  program,  for  example,  to 
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choose  hardware  configurations  first,  then  work  on  software.  The  negative  effects  of  this 
strategy  were  pointed  out  in  Chapter  II.  The  use  of  an  appropriate  acquisition  strategy 
is  vital  to  the  success  of  the  program. 

2.      Acquisition  Strategy  Defined 

Acquisition  strategy  is  defined  in  the  Defense  Systems  Management  College 

Acquisition  Strategy  Guide  as: 

A  conceptual  basis  of  the  overall  plan  to  follow  in  program  execution.  The 
acquisition  strategy  is  the  basis  for  all  functional  strategies,  plans,  and  tasking;  it 
provides  a  coordinated  approach  to  achieving  program  objectives  within  the 
constraints  placed  on  the  program.  [Ref.  53:p  3-21] 

The  main  ingredients  for  successful  acquisition  of  systems  involves  strategic, 
technical,  and  resource  concerns.  Program  objectives  must  be  established,  controlled,  and 
assessed  to  permit  the  deployment  of  a  militarily  useful  system  that  meets  cost,  schedule, 
performance,  and  supportability  goals. 

The  acquisition  strategy  must  show  how  the  system  and  program  objectives 
will  be  met,  how  policy  and  procedures  will  be  accommodated,  and  how  the  conduct  of 
the  program  will  meet  such  criteria  as  realism,  stability,  resource  balance,  flexibility,  and 
controlled  risk.  [Ref.  53 :p  3-21] 

The  benefits  of  a  sound  acquisition  strategy  allow  the  program  manager  to 
maintain  control  and  provide  direction  to  his  management  effort.  Some  of  the  realized 
benefits  are: 

1.     Providing  a  consistent  and  organized  approach. 
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2.  Providing  a  coordinated  approach  to  achieving  program  objectives  economically 
and  effectively  through  informed  and  timely  decisions. 

3.  Providing  a  baseline  for  preparing  plans  and  activities  to  facilitate  program 
understanding  and  agreement. 

4.  Documenting  decisions  and  assumptions  made  in  the  process  of  acquisition. 

5.  Providing  important  political  credibility.  [Ref.  53:p  3-2] 

These  are  more  than  just  benefits,  they  are  crucial  to  a  systems  success. 
Without  them,  political  support,  and  hence  financial  support,  is  difficult  to  maintain. 

The  acquisition  strategy  should  be  determined  as  early  in  the  systems  life  cycle 
as  possible.  The  impact  of  decisions  made  early  in  the  cycle  substantially  determine  the 
majority  of  the  costs  later  in  the  cycle. 
[Ref.  53:p  3-2] 

3.      The  MTACCS  Acquisition  Strategy 

a.      Evolutionary  Acquisition 

The  MTACCS  acquisition  concept  is  a  "build  a  little,  test  a  little,  field 

a  little"  approach  using  off-the-shelf  equipment  and  software  where  applicable.    It  is  a 

strategy  known  as  "Evolutionary  Acquisition".   Evolutionary  Acquisition  is  defined  as: 

An  acquisition  strategy  which  may  be  used  to  procure  a  system  expected  to  evolve 
during  development  within  an  approved  architectural  framework  to  achieve  an 
overall  systems  capability.  An  underlying  factor  in  Evolutionary  Acquisition  is  the 
need  to  field  a  well  defined  core  capability  quickly  in  response  to  a  validated 
requirement,  while  planning  through  an  incremental  upgrade  program  to  eventually 
enhance  the  system  to  provide  the  overall  system  capability.  These  increments  are 
treated  as  individual  acquisitions,  with  their  scope  and  context  being  the  result  of 
both  continuous  feedback  from  developing  and  independent  testing  agencies  and  the 
user...  [Ref.  54:p  23] 
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Requirements  are  to  originate  from  the  Fleet  Marine  Force  to  ensure  users 
needs  are  met.  System  development  must  be  managed  from  the  Program  Executive 
Officer  (PEO)  to  ensure  an  integrated  C2  system.  User  requirements  will  be  satisfied  in 
a  coordinated,  evolutionary  manner  using  non-developmental  automation  and 
secure/reliable  digital  communications  equipment.  [Ref.  l:p  7] 

The  MTACCS  Operational  Concept  Document  establishes  the  following 
policies: 


1.  Marine  Corps  requirements  for  new  acquisition  shall  be  satisfied,  whenever 
suitable  and  acceptable,  through  the  programs  of  other  services,  government 
agencies,  or  joint  developmental  efforts. 

2.  When  existing,  proven  technology  will  satisfy  a  requirement,  it  shall  be  used. 
Standard  Marine  Corps  equipment  and  other  off-the-shelf  components  shall  be 
used  unless  specific  justification  to  do  otherwise  is  provided.  [Ref.  1:  Appendix  B] 


Again,  these  policies  imply  the  maximum  use  of  Non-Developmental  Items  (NDI)  and 
Commercial  Off-The-Shelf  (COTS)  material. 

Evolutionary  acquisition  is  an  alternative  acquisition  process  used  to  acquire 
command  and  control  systems  that  are  expected  to  evolve  during  development  and 
throughout  their  operational  life. 

Figure  22  graphically  represents  the  application  of  an  evolutionary  acquisition 
approach.  The  figure  emphasizes  that  the  initial  preliminary  system  architecture  is 
segregated  into  planned  increments.  Those  increments  are  then  refined,  funded,  and 
developed  in  stages.  [Ref.  55] 
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Figure  22:  A  Model  of  Evolutionary  Acquisition  [Source:  Ref.  55] 
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b.      Motivation  for  Employing  Evolutionary  Acquisition 

The  Marine  Corps  has  chosen  to  develop  MTACCS  through  the  use  of 
Evolutionary  Acquisition  for  several  reasons: 

(1)  Lessons  Learned  From  MIFASS.  As  discussed  in  Chapter  II,  the 
Marine  Corps'  attempt  at  the  "big  system  approach"  has  failed  miserably  in  the  past  at 
extreme  cost.  It  was  simply  too  hard  to  adjust  requirements  and  specifications  to  keep 
up  with  both  user  demand  and  technology,  and  quickly  incorporate  these  adjustments  into 
a  system.  [Ref.  32:p  16]  Using  Evolutionary  Acquisition,  improvements  or  changes  can 
be  made  at  the  next  incremental  upgrade  and  can  be  made  easily  if  the  original  core 
design  was  built  with  changes  in  mind. 

(2)  Lack  of  a  Firm,  Complete  List  of  Defined  Requirements.  A  complete 
list  of  C2  automation  or  support  requirements  would  be  impossible  to  generate.  The 
introduction  of  new  technology  and  procedures  makes  old  tasks  easier  and  opens  the  door 
to  provide  new  capabilities.  This  makes  it  difficult  to  predict  the  final  requirements.  [Ref. 
32:p  16]  By  using  Evolutionary  Acquisition,  the  user  can  provide  timely,  accurate 
feedback  of  what  he  wants,  needs,  and  actually  uses.  This  feedback  can  be  applied  to  the 
next  increment  and  tested. 

(3)  Growing  Political  Acceptance  of  Evolutionary  Acquisition.  The  use 
of  Evolutionary  Acquisition  as  an  alternative  acquisition  strategy  is  consistent  with  the 
guidance  of  OMB  Circular  A- 109,  DoD  Directive  5000.1,  and  with  Defense  Acquisition 
Circular  76-43.    Evolutionary  Acquisition  encourages  regular  and  continual  interaction 
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with  Deputy  Program  Managers  (DPM)24,  requirements  proponents,  users,  developers, 
testers,  and  logisticians.  It  encourages  the  consideration  of  Non-Developmental-Items 
(NDI)  and  Commercial-Off-the-Shelf  (COTS)  materiel  where  applicable.  [Ref.  32:p  16] 
By  this  continual  interaction,  the  risk  of  spending  a  large  amount  of  resources  with  no 
measurable  return  is  reduced.  The  program  is  reviewed  by  all  concerned  at  each 
increment.  Those  responsible  for  certain  fields  will  have  to  interact  repeatedly  with  those 
responsible  for  the  other  fields  that  could  effect  them. 

(4)  The  Ability  to  Impact  and  Coordinate  Subordinate  Programs.  Since 
several  of  the  MTACCS  component  systems  are  being  developed  by  separate  DPMs  under 
the  PM,  M  AGTF  C2,  each  DPM  will  be  given  the  same  set  of  standards,  interface  criteria, 
and  requirements  to  incorporate  into  their  systems.  The  DPMs  will  manage  the 
development  of  their  separate  systems,  but  with  a  common  goal  to  be  achieved.  Their 
progress  will  be  reviewed  for  compatibility  by  the  same  senior;  one  person,  not  a 
revolving  committee.  [Ref.  32:p  17]  This  will  help  to  ensure  that  MTACCS  subsystems 
are  interoperable  and  the  Marine  Corps  will  not  suffer  drastic  logistical  burdens 
supporting  a  multitude  of  completely  different  systems. 

(5)  The  User  Response  is  Quickly  Incorporated.  By  starting  with 
equipment  and  procedures  the  user  is  already  familiar  with,  and  incorporating  a  limited 
amount  of  change  at  each  increment,  the  user  can  easily  assimilate  and  evaluate  the 


Deputy  Program  Managers  are  responsible  for  subsystems  under  the  MTACCS 
engineering  effort.   They  report  to  the  PM,  MAGTF  C2. 
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change,  providing  appropriate  and  accurate  feedback.    Through  the  use  of  FDS,  this  is 
possible. 

(6)  Capabilities  are  Fielded  Faster.  Evolutionary  Acquisition  permits 
faster  fielding  of  core  capabilities  to  the  user.  It  allows  building  on  existing  equipment 
and  systems  to  quickly  field  a  useful  core  capability  and  concurrently  develop  component 
systems,  capitalizing  on  the  ability  to  incorporate  component  systems  as  they  complete 
their  individual  development  phases.  [Ref.  32: p  16]  This  permits  new  technology  to  reach 
the  user  at  a  rate  that  is  much  faster  than  currently  possible. 

4.      Assessment  of  the  Feasibility  of  the  Evolutionary  Acquisition  Strategy 

a.      Emergence  of  Evolutionary  Acquisition 

Evolutionary  Acquisition  is  gaining  recognition  as  a  strategy  that  provides 

the  flexibility  necessary  to  adapt  evolving  command  and  control  systems.    Robert  R. 

Everett  has  written: 

I  believe  that  to  resort  to  evolution  is  not  a  failure  of  the  overall  design  process,  but 
recognition  that  evolution  is  the  way  that  complex  systems  actually  do  change. 
[Ref.  40] 

In    1987,   the   Joint  Logistics   Commanders25   endorsed   a  guide   for 

evolutionary  acquisition.  The  guide  was  prepared  by  the  Defense  Systems  Management 

College.   The  guide  noted: 


The  Joint  Logistics  Commanders  are  the  Commander,  U.S.  Army  Materiel 
Command,  the  Deputy  Chief  of  Naval  Operations  (Logistics),  the  Commander,  Air  Force 
Logistics  Command,  and  the  Commander,  Air  Force  Systems  Command. 
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Significant  studies  have  been  conducted  in  the  field  of  evolutionary  acquisition 
by  authoritative,  learned  and  experiences  groups  representative  of  public  and  private 
sectors  of  our  economy.  These  studies  have  concluded  that  for  the  acquisition  of 
C2  systems  an  evolutionary  approach  should  normally  be  used.  [Ref.  55] 

Brigadier  General  Edward  Hirsch26,  USA  (Ret),  wrote  in  an  article  in 

Signal  magazine: 

Evolutionary  Acquisition  is  not  a  cure-all  for  the  real  or  perceived  ills  of  the  U.S. 
acquisition  process;  but  it  does  hold  some  promise  to  help  field  command  and 
control  systems  sooner,  at  lower  cost  and  with  higher  user  satisfaction  than  other 
approaches.  [Ref.  54:p  23] 

b.      Non-Developmental  Items  and  Commercial-Off-The-Shelf  Products 

Non-Developmental  Items  and  Commercial-Off-the-Shelf  products  are 
generic  terms  that  describe  material  available  from  a  variety  of  sources  with  little  or  no 
development  by  the  government.  These  are  items  that  are  either  available  in  the 
commercial  market  place  or  from  other  services. 

According  to  William  H.  Taft  IV27,  'The  use  of  Off-The-Shelf  sources 
is  a  major  initiative  of  the  Department  of  Defense  [Ref.  56:p  103].  There  is 
considerable  motivation  for  the  Marine  Corps  to  pursue  this  element  of  acquisition 
strategy  wherever  possible.  Non-Developmental  Items  yield  several  benefits: 

1.  The  time  in  development  and  the  time  to  fielding  is  gready  reduced. 

2.  Users  requirements  and  needs  can  be  met  and  satisfied  quickly. 


Director,   Center  for  Acquisition   Management  Policy,   Defense   Systems 
Management  College  at  the  time  of  publication  of  the  article. 

27 


Former  Deputy  Secretary  of  Defense. 
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3.  Costs  for  Research  and  Development  are  reduced. 

4.  Current,  state  of  the  art  technology  is  used  and  fielded.  [Ref.  57] 

However,  there  are  risks  involved  with  using  Non-developmental  Items. 
These  include: 


1 .  Cost  and  performance  tradeoffs  to  accommodate  the  use  of  NDI  components  in 
production. 

2.  The  resulting  proliferation  of  hardware  and  software  can  cause  logistic  support, 
training,  and  configuration  management  problems  and  possible  increased  life  cycle 
costs. 

3.  Safety  deficiencies  may  occur  because  the  NDI  was  not  built  specifically  for  a 
military  environment.  [Ref.  57] 


The  benefits  of  using  NDI  should  aid  in  the  fielding  of  MTACCS 
tremendously.  The  risks  are  being  minimized  through  the  use  of  the  common  hardware 
and  common  software.  By  restricting  the  amount  and  type  of  each,  many  of  the  logistical 
and  training  burdens  are  alleviated. 

c.      Conclusions  on  Acquisition  Strategy 

The    Evolutionary    Acquisition    strategy    is    widely    accepted    as    an 

appropriate  method  for  developing  complex,  integrated  systems.   William  E.  Leigh  and 

Clifford  Burgess28  assert  in  their  book  Distributed  Intelligence: 

Building  complex,  integrated  systems  in  a  single  project  seldom  is  successful  and 
rarely  is  attempted.  Normally,  integrated  systems  are  the  result  of  an  evolutionary 


Associate  Professors,  University  of  Southern  Mississippi  when  they  published 
their  book  in  1987. 
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sequence  of  development,  modification,  and  enhancements  of  multiple  systems 
originally  designed  to  operate  in  a  stand  alone  fashion.  [Ref.  39:  p  50] 

...  attempting  to  solve  a  problem  or  set  of  problems  that  is  too  large  in  scope 
virtually  guarantees  that  the  solution  will  be  obsolete  by  the  time  it  is  developed 
fully.  [Ref.  39:p  56] 

...  options  that  can  be  implemented  as  modules  that  are  relatively  narrow  in  scope 
are  becoming  increasingly  attractive.    [Ref.  39:p  56] 

The  use  of  this  strategy  in  the  development  and  procurement  of  MTACCS 

dramatically  increases  the  probability  of  success,  but  it  is  still  not  tested  on  a  project  of 

such  complexity. 

G.      CONCLUSIONS  ON  FEASIBILITY 

The  MTACCS  concept  is  feasible.  The  use  of  an  Evolutionary  Acquisition  strategy 
markedly  strengthens  the  program.  In  an  evolutionary  ,  incremental  development, 
advances  in  technology  can  be  more  readily  introduced  as  upgrades  to  the  core  system. 
There  are  several  factors,  however,  that  can  undermine  the  basic  feasibility  of  the  project. 
These  factors  must  be  addressed  and  mitigated  to  ensure  they  do  not  inhibit  development. 

1.      Use  of  Data  Communications 

The  MTACCS  program  must  ensure  that  informal  communications  and  voice 
radio  are  not  entirely  supplanted  by  data  communications.  To  rely  too  heavily  on  data 
transmissions  violates  the  spirit  of  Marine  Corps  doctrine  and  runs  the  risk,  as  Van 
Creveld  said,  of  "reducing  command  to  trivia"  [Ref.  41:p  273]. 
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2.  Centralization 

A  clear  vision  of  the  degree  of  centralization  of  command  and  control  must 
be  established  early  and  maintained.  In  addition,  it  is  vital  that  the  degree  of 
centralization  be  strongly  supported  across  the  entire  Marine  Corps.  There  must  be 
consensus.    Division  on  this  highly  critical  issue  can  cripple  the  program. 

3.  Communications  Capacity 

The  simultaneous  development  of  both  MTACCS  and  its  supporting 
communications  system  is  a  hauntingly  familiar  scenario.  The  MIFASS  system  was  also 
intended  to  operate  with  communications  equipment  that  was  being  developed 
concurrently.  When  the  communications  equipment  experienced  delays,  MIFASS  was 
handicapped.  It  did  not  have  a  communications  system  capable  of  providing  adequate 
support.  The  Marine  Corps  must  be  very  concerned  that  this  does  not  occur  again  with 
the  "revitalized"  MTACCS.  The  Naval  Research  Advisory  Committee  has  cast  doubts 
on  the  ability  of  both  current  and  future  communications  equipment  to  handle  the  load. 
Action  must  be  taken  to  plan  for  that  contingency. 

4.  Multi-level  Security 

Continued  emphasis  must  be  placed  on  establishing  multi-level  security  if  TCO 
is  to  interface  with  IAS  and  provide  unit  commanders  with  real  time  intelligence. 
Without  a  demonstrated  secure,  trusted  system,  there  will  be  little  user  support  for 
allowing  classified  information  of  a  sensitive  nature  to  be  passed  on  MTACCS  nets. 
There  is  a  need  to  allow  users  of  differing  security  levels  to  be  able  to  access  the  same 
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system  using  the  same  database.  Until  this  can  be  done  with  a  high  degree  of  confidence, 
our  intelligence  system  could  be  unintentionally  violated.  Fortunately,  there  appears  to 
be  a  strong  interest  displayed,  by  both  industry  and  the  services,  in  the  development  of 
multi-level  security  for  both  military  and  commercial  applications.  It  appears  that  the 
Marine  Corps  need  only  follow  those  developments  closely  and  evaluate  candidate 
methods  to  determine  the  method  most  appropriate  for  Marine  Corps  needs. 

5.      Software  Development 

Software  development  continues  to  be  DOD's  "Achilles'  heel".  The  MTACCS 
development  team  has  laid  out  a  development  plan  that  incorporates  the  best  advice  of 
the  time.  However,  the  plan  must  be  adhered  to.  The  software  must  be  adequately  tested 
and  progress  demonstrated  to  avoid  making  decisions  based  on  promises  and  reputations 
as  MIFASS  did.  The  acquisition  strategy  must  be  able  to  react  to  new  technologies, 
processes,  and  strategies. 
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V.   COST-EFFECTIVENESS  ASSESSMENT 

A.      INTRODUCTION 

1.  Purpose  of  this  Chapter 

The  purpose  of  this  chapter  is  to  examine  the  combat  effectiveness  of 
MTACCS  in  relation  to  its  cost.  Automation  of  a  particular  task  or  set  of  procedures  is 
generally  thought  to  improve  combat  effectiveness.  While  MTACCS  may  indeed  improve 
the  efficiency  with  which  assets  are  used  and  increase  the  overall  effectiveness  of  the 
Marine  Corps,  is  it  the  most  cost  effective  method?  Could  the  same  level  of  effectiveness 
be  achieved  at  a  lower  expenditure  of  resources  if  something  else  was  purchased?  These 
questions  will  be  addressed  here. 

2.  The  Importance  of  a  Cost-Effectiveness  Assessment 

The  procurement  of  a  C2  system  as  extensive  as  MTACCS  is  an  expensive 
proposition.  Hundreds  of  millions  of  dollars  were  spent  on  the  failed  MIFASS  system 
alone.  Given  this  significant  investment,  several  vitally  important  issues  must  be 
addressed: 

1.  Is  it  worth  the  expense? 

2.  Will  it  significantly  enhance  combat  effectiveness? 

3.  Would  the  Marine  Corps  be  better  off  to  buy  more  weapons  and  less  C2? 

4.  What  is  the  most  cost-effective  level  of  automation? 
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These  are  difficult  questions  to  answer.  The  information  presented  here 
provides  insight  to  possible  answers,  but  does  not  address  the  level  of  detail  necessary  to 
determine  the  best  answers. 

3.      Assessment  Methodology 

Questions  of  this  nature  are  generally  answered  by  cost-effectiveness  studies. 
A  complete  cost-effectiveness  study  of  MTACCS  as  it  currently  stands,  is  beyond  the 
scope  of  this  thesis.  Fortunately,  several  cost-effectiveness  studies  have  been  completed. 
Two  of  these  studies  will  serve  as  a  foundation  for  an  assessment  of  the  potential  of  the 
"revitalized"  MTACCS  to  enhance  combat  effectiveness.  Both  were  conducted  in  1981 
by  the  Center  for  Naval  Analyses  (CNA).  The  first  is  a  study  of  the  Tactical  Combat 
Operations  (TCO)  system  as  it  stood  then.  The  second  addresses  the  Marine  Air  Ground 
Intelligence  System  (MAGIS). 

Cost-effectiveness  may  be  assessed  in  two  parts:  combat  effectiveness  and 
cost-effectiveness.  First,  the  combat  effectiveness  section  will  examine  the  change  in 
combat  capability  that  MTACCS  may  provide.  The  cost-effectiveness  section  then  relates 
the  amount  of  change  in  combat  effectiveness  that  can  be  attributed  to  MTACCS  to  the 
resource  cost  of  the  system. 

This  chapter  will  use  TCO  as  its  primary  example  due  to  the  role  TCO  will 
maintain  as  the  system  integrator  for  MTACCS.  It  is,  in  essence,  the  hub  of  MTACCS. 
TCO  possesses  the  functions  and  tools  with  which  to  allocate  forces  and  assets,  while 
processing  intelligence,  and  disseminating  orders  and  plans.  TCO  is  the  primary 
component  of  the  initial  MTACCS  development.     It  is  geared  towards  providing 
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automated  assistance  for  MAGTF  command  and  control  through  the  integration  of  the 
MTACCS  component  systems.  An  assessment  of  TCO  will  closely  approximate  an 
assessment  of  the  integrated  MTACCS  system. 

Additionally,  a  second  CNA  study  that  addresses  the  Marine  Air  Ground 
Intelligence  System  (MAGIS)  Intelligence  Analysis  Center  (IAC)  is  reviewed.  The  IAC 
study  has  two  drawbacks,  however.  First,  only  measures  of  performance  were  tabulated. 
Measures  of  force  effectiveness  were  not  considered.  Second,  a  cost-effectiveness  trade- 
off between  the  manual  system  and  the  IAC  was  not  developed. 

4.      Limitations  of  the  Assessment 

The  CNA  studies  were  completed  ten  years  ago,  well  before  the 
"revitalization"  of  MTACCS.  This  places  limits  on  the  validity  of  an  assessment  of  the 
"new"  MTACCS.  Extensive  similarities  remain,  however,  and  much  of  the  analysis  of 
the  earlier  version  of  these  can  be  applied  today.  The  cost-effectiveness  studies  are  used 
to  illustrate  the  potential  benefits  and  limitations  of  an  automated  C2  system. 

B.      THE  IMPACT  OF  MTACCS  ON  COMBAT  EFFECTIVENESS 

An  evaluation  of  combat  effectiveness  usually  requires  extensive  modeling  and 
simulation.  Modeling  and  simulation,  however,  are  outside  the  scope  of  this  assessment. 
Trie  impact  of  MTACCS  on  combat  effectiveness  will  be  concluded  from  prior  studies. 
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1.      The  Center  for  Naval  Analyses  TCO  Assessment 

a.      Background 

The  basic  approach  used  in  the  TCO  analysis  was  a  three  tiered  approach. 
Each  alternative  was  evaluated  on  a  first  level  using  measures  of  performance  (MOP's), 
on  a  second  level  using  measures  of  effectiveness  (MOE's),  and  on  a  third  level  using 
measures  of  force  effectiveness  (MOFE's).  The  study  concluded  with  the  evaluation  of 
the  effectiveness  of  equal -cost  alternatives.  [Ref.  58:p  1]  Five  relevant 
alternatives  were  analyzed,  four  variations  of  TCO29  and  a  manual  system: 

1.  Full  TCO  -  TCO  as  described  in  Chapter  III  with  fully  functioning  nodes  down 
to  the  battalion/squadron  level. 

2.  Nodallv  Austere  TCO  -  The  nodes  at  the  battalion/squadron  level  were  eliminated. 

3.  Functionally  Austere  TCO  -  Decision  aids  were  eliminated  at  all  levels. 

4.  Very  Austere  TCO  -  The  nodes  at  the  battalion/squadron  level  were  eliminated 
and  the  decision  aids  at  all  levels  were  eliminated. 

5.  Manual  System  -  The  majority  of  information  was  maintained  on  status  boards, 
overlays,  and  paper  files. 


The  CNA  analysis  evaluated  TCO  with  the  MIFASS  concept  before  the 
revitalization  of  MTACCS  in  1989.  Since  the  majority  of  the  MTACCS  subsystems  were 
in  the  development  phase,  only  the  concepts  and  not  the  systems  themselves  were  being 
analyzed.   The  concept  for  TCO  has  remained  essentially  the  same  in  many  respects. 
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b.      Evaluation  Criteria 

(1)    Measures  of  Performance 

(a)  Timeliness.  Timeliness  represents  the  time  that  elapses  between 
the  first  occurrence  of  an  event  and  when  information  concerning  that  event  is  processed 
and  translated  into  action. 

(b)  Accuracy.  Accuracy  is  the  degree  of  correctness  of  the 
information  in  the  system.  Each  system  can  only  be  as  accurate  as  the  information  put 
into  it.  [Ref.  58:p  7]  It  is  assumed  that  the  same  caliber  of  input  is  used  in  each  case,  and 
the  measurement  of  accuracy  is  in  the  transmission  of  the  data.30 

(c)  Decision  Aids.  The  change  in  effectiveness  due  to  decision  aids 
was  measured  through  the  use  of  three  decision  aids:  Battlefield  Simulation,  Air  Routing, 
and  Air  Weaponeering.  Battlefield  Simulation  is  basically  a  war  game  with  which  to  test 
and  improve  operational  plans  before  implementation.  Air  Routing  allows  the  pilot  to 
choose  the  optimal  route  with  an  Electronics  Counter  Measures  (ECM)  plan  to  ensure 
survival  and  mission  effectiveness.  Air  Weaponeering  aids  in  matching  targets  with 
optimal  weapons.31  [Ref.  58 :p  6] 


In  a  manual  system,  information  can  be  significantly  delayed  resulting  in 
erroneous  perceptions.  These  delays  are  usually  due  to  voice  transmission  taking  too  long 
to  convey  information  and  having  to  wait  for  a  turn  on  the  net.  In  an  automated  system, 
messages  generally  travel  faster  with  greater  accuracy. 

31         The  current  TCO  system  has  not  yet  identified  the  decision  aids  to  be  included. 
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(2)  Measures  of  Effectiveness 

(a)  Perceptions.  The  commander's  estimate  of  enemy  strength  was 
used  as  an  indication  of  his  perception  of  the  battlefield.  [Ref.  58:p  6] 

(b)  Resource  Allocation.  The  allocation  of  rifle  squads  between 
front  line  battalions  and  the  reserves  was  used  as  an  indication  of  resource  allocation. 
The  more  accurate  the  commander's  perception  of  the  battlefield,  the  more  accurately  he 
can  allocate  his  forces.  [Ref.  58:p  6] 

(3)  Measure  of  Force  Effectiveness.  The  loss  ratio  was  used  as  a 
measure  of  force  effectiveness.  The  loss  ratio  was  defined  as  the  ratio  of  enemy  losses 
to  friendly  losses  after  two  days  of  simulated  battle.  [Ref.  58:p  6] 

c.      Effectiveness  Results 

(J)  Time  Delay  (Figure  23).  There  is  a  readily  observable  difference 
between  the  automated  systems  and  the  manual  system.  This  was  attributed  to  increased 
processing  speed  and  transmission  speed.  The  human  processing  at  the  receiver  is 
considered  the  same  for  each  system.  It  became  apparent  that  decision  aids  are  not  a 
factor  in  the  speed  of  the  decision  based  on  these  results.  [Ref.  58 :p  4] 

(2)  Error  Rates  (Figure  23).  Again,  there  appears  to  be  a  significant 
difference  between  automated  and  manual  systems.  Automated  systems  demonstrate  half 
the  error  rate  of  the  manual  system. 
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Figure  23:  Error  Rates  and  Time  Delay  [Source:  Ref.  58] 


(3)  Decision  Aids.  In  the  analysis,  Battlefield  Simulation  yielded  a  26% 
decrease  in  the  rate  of  friendly  casualties.  Air  Routing  produced  a  30%  reduction  in 
aircraft  vulnerability.  Air  Weaponeering  increased  the  effectiveness  of  delivered  ordnance 
by  76%.  [Ref.  58:p  5]  Gearly,  decision  aids  can  contribute  greatly  to  the  combat 
effectiveness  of  a  force. 

(4)  Perceptions   (Figure  24).      The   study   also   analyzed   how   the 

improvements  in  a  C2  system  can  impact  the  commander's  perception  of  the  battlefield. 

The  starting  premise  was: 

The  current  perception  is  a  function  of  the  previous  perception  and  the  "new" 
information  that  is  becoming  available.  Due  to  time  delays  in  the  system,  the 
"new"  information  may  be  hours  old.  These  two  factors  are  weighted  so  that  the 
higher  the  confidence  in  the  "new"  information,  the  more  reliance  on  it. 
[Ref.  58:p  6] 
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figure  24:  Perceptions  of  Enemy  Strength  in  the  TCO  assessment  [Source:  Ref. 

58] 


It  became  obvious  from  the  results  and  from  military  experience,  that 
perceptions  will  tend  to  lag  behind  the  actions  and  intentions  of  the  enemy.  Figure  24 
depicts  this  time  lag  of  friendly  perceptions  and  enemy  actions.  The  analysis 
demonstrated  that  the  automated  system  had  roughly  a  one  hour  time  lag  while  the 
manual  system  averaged  a  four  hour  time  lag.  There  was  also  a  noticeable  difference  in 
the  accuracy  of  the  commander's  perception.  Accuracy  in  enemy  strength  showed  an 
average  error  of  1300  soldiers  for  the  manual  system.  The  average  error  was  only  350 
soldiers  for  the  automated  system.  Overall,  the  automated  system  resulted  in  a  much 
more  accurate  perception  of  the  battlefield. 
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(5)  Resource  Allocation.  Resources  were  allocated  based  on  perceptions. 
Figure  25  shows  the  movements  of  rifle  squads  between  the  front  lines  and  the  reserves. 
The  allocation  of  rifle  squads  was  based  on  a  fixed  decision  rule  which  was  a  function 
of  the  current  battlefield  perceptions.  Therefore,  the  more  accurate  the  perception  of 
enemy  forces  and  intent,  the  more  appropriate  and  effective  the  allocation.  The  manual 
system,  due  to  its  inaccuracies  in  perception,  assigned  rifle  squads  in  a  poor  fashion  as 
compared  to  the  more  accurate  TCO  system.  [Ref.  58:p  6] 
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Figure  25:  Resource  Allocation  in  the  TCO  assessment  [Source:  Ref.  58] 

(6)  Loss  Ratio.  In  the  analysis32,  battle  outcome  was  determined  by 
the  final  loss  ratio.  The  results  were  all  normalized  and  portrayed  relative  to  friendly 
losses.  Command  and  control  was  incorporated  by  keeping  track  of  the  two  views  of  the 


The  analysis  used  a  deterministic,  two  sided  computer  model  know  as  the  C2 
Model.  The  model  portrays  a  large  scale  amphibious  assault  of  a  Marine  Expeditionary 
Force. 
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battlefield;  the  commander's  perception  and  the  actual  situation.  Plans,  resource 
allocation,  and  control  of  the  battle  were  conducted  based  on  the  commander's 
perceptions.  The  outcomes  of  the  commander's  decisions,  of  course,  were  based  on  the 
actual  situation.  Table  I  shows  the  resulting  final  loss  ratios.  [Ref.  58:p  8]  The  ratios  can 
be  roughly  segregated  into  three  levels  of  effectiveness.  The  Full  TCO  and  Nodally 
Austere  TCO  achieved  a  similar  level  of  effectiveness,  performing  significantly  better  than 
all  of  the  other  systems.  The  Functionally  Austere  TCO  and  Very  Austere  TCO  both 
performed  at  a  similar  level  of  effectiveness  that  was  significantly  lower  than  the  other 
two  automated  alternatives.  The  overriding  difference  between  these  two  and  the  other 
automated  systems  is  in  the  use  of  decision  aids.  The  values  shown  in  Table  I  illustrate 
the  relatively  higher  value  of  decision  aids  compared  to  that  of  having  additional 
automation  at  lower  echelons.  Again,  this  implies  that  decision  aids  can  significantly 
impact  the  outcome  of  the  battle. 

2.      The  Center  for  Naval  Analyses  MAGIS  Assessment 

a.      Background 

The  CNA  analysis  focused  on  a  cost  and  operational  analysis  assessment 
of  the  MAGIS  Intelligence  Analysis  Center  (IAC).  Three  automated  alternatives  to  the 
IAC  were  considered,  but  none  were  found  to  be  suitable.  These  were  the  existing 
intelligence  systems  of  the  Army,  Navy,  and  the  Air  Force.  The  study,  then,  compared 
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Table  I:  LOSS  RATIOS  IN  THE  TCO  ASSESSMENT 
[Source:  Ref.  58] 


RELATIVE 
ALTERNATIVE  LOSS  RATIO 

FULL  TCO    1.14 

NODALLY  AUSTRER  TCO     1 .  11 

FUNCTIONALLY  AUCTERE  TCO     1 .  04 

VERY  AUSTERE  TCO     1.03 

MANUAL     1.00 


only  two  alternatives:  the  IAC  and  a  manual  system.  The  effectiveness  data  came  from 
two  sources.  The  1975  operability  test  of  the  Intelligence  Analysis  Storage  and  Retrieval 
System  was  the  source  for  manual  data.  The  1979  Developmental  Test  II  of  the  IAC 
provided  data  for  the  automated  alternative.  [Ref.  46:p  v] 

b.      Methodology 

In  the  previous  TCO  analysis,  a  three  tiered  approach  was  used.  The 
TCO  system  was  evaluated  against  measures  of  performance  (MOP),  measures  of 
effectiveness  (MOE),  and  lastly,  measures  of  force  effectiveness  (MOFE's).  In  the  IAC 
analysis,  only  performance  was  measured.  [Ref.  59] 
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c.  Measures  of  Performance 

The  measures  of  performance  used  during  the  IAC  analysis  are  defined 
here. 

(1 )  Percentage  of  Required  Products  Produced.  The  number  of  required 
products  that  are  actually  produced  by  the  test  team  divided  by  the  total  number  required. 
[Ref.  59:p  33] 

(2)  Completeness.  The  percentage  of  items  that  are  complete,  based  on 
those  outputs  that  are  actually  produced.  The  percentage  is  obtained  by  comparing  the 
items  completed  by  the  test  team  with  the  predetermined  solution.  [Ref.  59:p  33] 

(3)  Accuracy.  The  percentage  of  those  items  completed  that  are  correct, 
based  on  the  predetermined  solutions.  [Ref.  59:p  33] 

(4)  Timeliness.  The  deviation  between  the  actual  output  time  and  the 
scheduled  output  time.  A  negative  timeliness  score  indicates  that  the  output  was  produced 
earlier  than  required.  [Ref.  59:p  34] 

d.  Summary  of  Effectiveness  Results  in  the  IAC  Analysis 

The  CNA  study  concluded  that  the  IAC  was  a  significant  improvement 
over  the  manual  system.  Test  results  showed  that  the  IAC  provided  a  marked  measure 
of  improvement  in  the  first  three  of  the  performance  measures.  The  measure  of 
timeliness,  however,  greatly  favored  the  manual  system.  For  this  reason,  the  analysts 
expressed  concern  that  the  results  of  the  two  tests  were  not  entirely  comparable  in  the 
timeliness  measure.   Some  limitations  were  developed  as  a  result  of  these  conclusions. 
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e.      Limitations  of  the  CNA  MAGIS  Assessment 

(1)  MOP's  versus  MOFE's.  Measures  of  performance  (MOP's)  are  an 
indicator  of  the  isolated  performance  of  the  system  only.  MOP's  do  not  provide  an 
accurate  indication  of  the  overall  impact  on  combat  effectiveness.  [Ref.  59] 

(2)  Two  Tests  not  Entirely  Compatible.  As  mentioned  earlier,  the  results 
of  the  two  tests  were  compiled  to  produce  the  MAGIS  IAC  assessment.  These  tests  were 
not  administered  under  the  same,  or  in  some  cases,  even  similar  conditions.  CNA 
analysts  were  required  to  manipulate  the  test  data  to  achieve  a  rough  comparability 
between  the  tests.  [Ref.  59] 

(3)  Production  of  Required  Reports.  In  the  manual  method,  production 
of  required  reports  could  begin  at  any  time.  Intelligence  personnel  were  able  to  start 
reports  well  before  the  required  delivery  time  based  on  information  available  at  the  time. 
Users  of  the  automated  system  were  not  permitted  to  begin  report  preparation  until  a 
certain  time  prior  to  the  required  delivery  time.  [Ref.  59] 

/.       Conclusions  on  the  Effectiveness  of  the  IAC 

The  CNA  analysis  revealed  that  automation  of  the  intelligence  system  has 
the  potential  to  substantially  improve  system  performance.  The  analysis  has  limited 
utility,  however,  because  it  did  not  address  the  potential  of  the  automated  system  to 
improve  force  effectiveness. 
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C.      COST-EFFECTIVENESS 

1.  Definition 

Cost-effectiveness  studies  generally  attempt  to  evaluate  the  effectiveness  of 
various  alternatives  on  a  common  scale,  then  relate  the  effectiveness  "score"  for  that 
system  to  its  cost.  A  system  is  most  cost-effective  when  it  provides  a  larger  incremental 
increase  in  effectiveness  per  unit  of  cost. 

2.  The  TCO  Cost-Effectiveness  Assessment 

a.  Background 

The  TCO  study  performed  an  equal  cost  analysis  with  the  five  systems 
described  earlier.  The  most  expensive  system,  full  TCO,  was  used  as  a  cost  baseline. 
The  difference  in  cost  between  the  Full  TCO  alternative  and  the  other  systems  was  used 
to  purchase  more  firepower.  Additional  tanks  were  added  to  the  less  expensive 
alternatives.  Figure  26  shows  the  breakdown  of  the  estimated  costs  of  the  C3  systems 
plus  the  number  of  tanks  added  to  achieve  equal  cost  forces.  Using  the  C2  model 
described  earlier,  the  equal  cost  forces  were  evaluated  and  the  final  loss  ratios  tabulated. 
[Ref.  58:p  10] 

b.  Cost-effectiveness  Results 

The  cost-effectiveness  results  in  Table  II  show  that  automation  of 
command  and  control  is  an  effective  method  of  increasing  combat  effectiveness.  It  is 
important  to  point  out,  however,  that  the  Full  TCO  was  not  the  best  performer.  The 
Nodally  Austere  TCO  system  did  achieve  a  higher  score  in  loss  ratio.    Although  the 
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Figure  26:  Equal  Cost  Forces  [Source:  Ref.  58] 

difference  may  not  be  statistically  significant,  the  implication  is  clear.  Given  the  ability 
to  buy  firepower,  or  C2,  or  a  combination  of  both,  choosing  a  proper  combination  may 
be  the  most  appropriate  decision. 

c.      Limitations  of  the  TCO  Study 

The  results  of  the  TCO  study  must  be  tempered  with  the  facts  that: 

1 .  Only  tanks  were  used  as  additional  sources  of  firepower.  If  the  money  had  been 
spent  on  helicopters,  artillery,  or  additional  forces  the  outcome  of  the  simulation 
could  have  been  different. 

2.  It  was  a  specific  scenario  against  a  specific  enemy. 

3.  Only  one  type  of  computer  model  was  used. 
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Table  II:  EQUAL  COST  LOSS  RATIOS  [Source:  Ref. 

58] 

ALTERNATIVE  LOSS  RATIO 

NODALLY  AUSTERE   1.14 

TCO 1.13 

VERY  AUSTERE  TCO 1.03 

FUNCTIONALLY  AUSTERE  TCO  1 .  01 

MANUAL  1 .  00 

4.     The  computer  model  is  only  a  representation  of  reality;  a  representation  of 
unknown  fidelity. 

d.      Summary 

The  Center  for  Naval  Analyses  study  of  the  TCO  system  showed  that  the 
automation  of  command  and  control  tasks  can  greatly  increase  combat  effectiveness.  It 
is  also  important  to  note  from  the  results,  that  automation  of  C2  below  the  regimental 
level  did  little  to  enhance  the  overall  force  effectiveness  results.  The  study  does  have 
limitations,  however,  particularly  in  the  use  of  additional  tanks  to  increase  fire  power. 
The  current  trend  in  the  Marine  Corps  is  towards  a  "lighter"  force.  The  addition  of  more 
tanks  is  an  unlikely  possibility. 
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D.      CONCLUSIONS 

The  "revitalized"  MTACCS  concept  intends  to  establish  "work  station  equipped 
nodes  at  every  echelon  throughout  the  MAGTF"  (underline  added)  [Ref.  l:p  7].  The 
MTACCS  Master  Acquisition  Plan  provides  a  communications  architecture  diagram  that 
implies  automation  will  be  provided  down  to  the  battalion  level  at  the  very  least 
[Ref.  32:p  6-8]. 

Based  on  the  results  of  the  TCO  study,  automation  of  this  degree  may  not  be  the 
most  cost-effective  method  of  increasing  combat  effectiveness.  The  study  showed  that 
the  Austere  TCO  performed  basically  as  well  as  Full  TCO.  This  can  lead  to  the 
conclusion  that  the  automation  of  the  lower  levels  is  not  as  effective  or  not  feasible. 
There  may,  however,  be  cause  to  doubt  the  applicability  of  these  results  to  the  TCO 
study.  The  apparent  lack  of  benefit  from  full  TCO  may  have  been  a  result  of  a  portability 
problem  that  no  longer  exists.  Ten  years  ago,  the  capability  of  portable  equipment  was 
minuscule  compared  with  current  capabilities.  Generally  a  large  heavy  piece  of 
equipment  was  necessary  to  achieve  any  significant  level  of  processing  capability.  TCO 
was  intended  to  use  the  same  equipment  as  MIFASS.  Recall  form  Chapter  II  that  the 
MIFASS  equipment  was  universally  recognized  as  too  heavy.  The  TCO  of  ten  years  ago 
may  have  overwhelmingly  encumbered  the  lower  echelons.  The  majority  of  the  lower 
command  levels  are  active  participants  in  "Maneuver  Warfare".  They  shoot  and  move  and 
stay  on  the  go.  Modern  data  processing  and  telecommunications  technologies,  however, 
have  the  potential  of  providing  sufficient  automation  to  the  lower  command  levels  in  a 
much  smaller,  much  lighter  package.  These  are  important  issues  that  should  be  examined 
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before  such  an  analysis  is  used  as  a  justification  for  a  particular  degree  of  automated 
command  and  control. 

The  most  significant  conclusions  to  be  drawn  from  this  chapter  are  these: 


1 .  Automation  of  command  and  control  functions  has  the  potential  to  significantly 
enhance  the  combat  effectiveness  of  the  Marine  Corps. 

2.  The  proper  level  of  automation  may  not  be  "all  you  can  get".  The  most  cost 
effective  level  of  automation  may  be  that  which  restricts  automation  to  the  higher 
headquarters;  regiments  and  above. 

3.  The  rapid  pace  of  technological  progress  in  data  processing  and 
telecommunications  calls  into  question  the  applicability  of  the  CNA  studies  to  the 
TCO  and  MAGIS  systems  of  today.  [Ref.  58:p  11] 
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VI.   COMBAT  DEVELOPMENT  ASSESSMENT 

A.      INTRODUCTION 

1.      Definition  of  Combat  Development 

The  Marine  Corps  recognizes  that  it  must  continually  evaluate  its  own  combat 
effectiveness  and  efficiency,  and  develop  guidance  and  direction  that  plans  the  course  of 
the  Marine  Corps  in  the  years  ahead.  Planning  that  course  and  guiding  the  Marine  Corps 
along  the  way,  is  called  combat  development.  The  responsibility  for  combat  development 
is  primarily  vested  in  the  aptly  named  Marine  Corps  Combat  Development  Command 
(MCCDC).  There  does  not  appear  to  be  a  formal  definition  of  combat  development.  For 
the  purposes  of  this  assessment,  combat  development  is  defined  as  the  evaluation  of 
current  combat  capabilities  and  effectiveness  and  the  subsequent  planning  and 
implementation  of  a  development  effort  designed  to  meet  anticipated  requirements. 
Mainly,  combat  development  consists  of: 

1.  Development  of  concepts,  plans,  and  doctrine. 

2.  Threat  assessment. 

3.  Development  of  training  requirements. 

4.  Identification  of  requirements  for  changes  to  doctrine,  training  requirements,  force 
structure,  and  equipment. 

5.  Development  of  required  operational  capabilities. 

6.  Mission  Area  Analysis.  [Ref.  26:p  3-21] 
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The  goal  of  combat  development  is  to  ensure  that  the  Marine  Air  Ground  Task 
Force  of  the  future  will  be  capable  of  effectively  accomplishing  its  assigned  missions  on 
the  battlefields  of  the  future. 

2.  The  Impact  of  Combat  Development  on  MTACCS 

The  MTACCS  program  is  a  direct  result  of  combat  development  efforts  in  the 
Marine  Corps.  It  was  through  combat  development  that  the  need  for  MTACCS  was 
determined.  Combat  development  will  continue  to  chart  the  course  of  MTACCS 
throughout  its  operational  life. 

3.  Objective 

The  objective  of  this  chapter  is  to  assess  the  combat  development  practices 
used  within  the  Marine  Corps  that  directly  impact  the  MTACCS  program.  These 
practices  will  play  a  major  role  in  shaping  the  evolution  of  MTACCS,  and  to  a  large 
degree,  will  determine  its  fate. 

4.  Lack  of  Contractor  Information 

The  systems  engineering  practices  used  by  contractors  will  also  impact  combat 
development  in  general  and  MTACCS  in  particular.  Pacific  Northwest  Laboratories 
(PNL)  is  the  system  engineer  and  integrator  for  MTACCS.  They  have  not  yet  formally 
published  their  Systems  Engineering  Management  Plan  (SEMP)  and  a  draft  could  not  be 
attained.  Many  other  contractors  including  Command  Systems  Incorporated  (CSI)  and 
Atlantic  Research  Corporation  (ARC)  are  working  on  various  segments  of  MTACCS. 
While  their  methods  would  be  necessarily  similar,  each  undoubtably  has  their  own 
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individual  approach  to  systems  engineering.  For  these  reasons,  the  systems  engineering 
methodology  employed  by  contractors  is  considered  beyond  the  scope  of  this  thesis  and 
will  not  be  assessed. 

5.  Assessment  Methodology 

Combat  Development  practices  in  the  Marine  Corps  are  similar  to  a  systems 
engineering  methodology.  The  objective  of  both,  in  the  simplest  sense,  is  to  develop  a 
"system"  that  can  effectively  accomplish  its  assigned  tasks.  An  assessment  of  combat 
development,  therefore,  can  be  accomplished  through  a  comparison  with  established 
systems  engineering  techniques.  The  methodology  for  assessment,  then,  consists  of  the 
following  steps: 

1.  Describe  current  Marine  Corps  combat  development  practices. 

2.  Describe  the  impact  of  these  practices  on  MTACCS. 

3.  Define  systems  engineering. 

4.  Develop  a  system  view  of  the  Marine  Corps. 

5.  Identify  the  impact  of  applying  systems  engineering  to  combat  development  in  the 
Marine  Corps. 

6.  Outline  of  this  Chapter 

Section  B  of  this  chapter  describes  in  general  terms  how  combat  development 
is  currently  accomplished  in  the  Marine  Corps.  Section  C  describes  the  impact  of  combat 
development  practices  on  MTACCS.  In  Section  D  of  this  chapter,  systems  engineering 
is  defined  and  explained.  This  definition  provides  the  basis  for  a  comparison  with  combat 
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development.  Systems  engineering  models  are  developed  to  establish  a  baseline  process 
for  effective  systems  engineering.  The  models  represent  an  ideal  systems  engineering 
effort;  everything  done  correctly.  Section  E  develops  a  system  view  of  the  Marine  Corps. 
In  section  F,  the  possible  impact  of  applying  a  systems  engineering  methodology  to 
combat  development  is  described. 

B.       COMBAT  DEVELOPMENT  IN  THE  MARINE  CORPS 

1.      The  Combat  Development  Team 

The  combat  development  team  in  the  Marine  Corps  is  primarily  composed  of 
three  organizations:  MCCDC,  MCRDAC,  HQMC.  Figure  27  outlines  the 
interrelationships  between  these  activities.  The  functions  and  responsibilities  of  these 
organizations  were  described  in  Chapter  III. 

a.  Marine  Corps  Combat  Development  Command  (MCCDC) 

The  Marine  Corps  Combat  Development  Command  (MCCDC)  is  tasked 
with  analyzing  current  and  anticipated  Marine  Corps  missions  and  developing  concepts, 
plans,  doctrine,  force  structure,  and  equipment  requirements  to  support  those  missions. 

b.  Marine  Corps  Research,  Acquisition,  and  Development  Command 

The  Marine  Corps  Research,  Acquisition,  and  Development  Command, 
as  its  name  implies,  is  primarily  tasked  with  managing  the  research,  acquisition,  and 
development  of  new  equipment  to  meet  the  needs  of  the  Marine  Corps.  MCRDAC,  then, 
provides  feedback  to  the  Combat  Development  Command  on  technological  capabilities. 


141 


Figure  27:  MCCDC,  MCRDAC,  HQMC  Interrelationships  [Source:  MCCDC] 
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c.      Headquarters  Marine  Corps 

Headquarters,  Marine  Corps  sets  policy  and  must  approve  combat 
development  recommendations. 

2.      Procedures 

Figure  28  provides  a  brief  overview  of  the  combat  development  cycle.  The 
combat  development  procedures  outlined  here  are  a  simplistic,  high  level  representation. 
Details  of  activities  occurring  within  the  organizations  have  not  been  presented. 
Additionally,  a  considerable  amount  of  operations  analysis  is  accomplished  by  activities 
external  to  the  Marine  Corps  such  as  the  Center  for  Naval  Analyses. 

a.      Mission  Area  Analyses 

In  many  cases,  the  combat  development  process  is  initiated  by  a  Mission 
Area  Analysis.  This  analysis  of  a  particular  mission  area,  such  as  intelligence  or 
command  and  control,  identifies  deficiencies  and  proposes  recommended  actions  for 
correction.  The  combat  development  process  then  analyzes  and  evaluates  the 
recommended  solutions.  Figure  29  gives  a  brief  description  of  the  process  from  a 
Mission  Area  Analysis  to  achievement  of  mission  capability. 

C.      THE  IMPACT  OF  COMBAT  DEVELOPMENT  ON  MTACCS 

Combat  development  is  a  complex  process.  The  description  of  combat  development 
presented  in  the  previous  section  only  scratches  the  surface  of  a  very  deep  subject.  For 
this  reason,  the  impact  of  combat  development  on  MTACCS  is  not  entirely  clear.  There 
appears  to  be  two  trends,  however,  in  the  recommendations  and  decisions  that  result  from 
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Figure  28:  The  Combat  Development  Process  [Source:  Authors] 
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Figure  29:  Mission  Area  Analysis  to  Mission  Capability  [Source:  Ref.  26] 
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the  combat  development  process.   From  these  trends,  it  is  possible  to  generalize  on  the 
probable  impact  of  combat  development  on  MTACCS. 

1.      General  Trends 

Mission  Area  Analyses  are  key  contributors  to  the  combat  development 
process.  The  recommendations  that  result  from  Mission  Area  Analyses,  and  subsequently 
from  the  combat  development  process,  appear  to  follow  two  general  trends.  These  trends 
will  likely  have  an  impact  on  the  development  of  MTACCS. 

a.      An  Equipment  Orientation 

The  majority  of  recommendations  appear  to  be  equipment  oriented; 
relating  to  improvement  of  existing  equipment  or  the  acquisition  of  new  material  or 
equipment.  An  examination  of  two  recently  completed  Mission  Area  Analyses  revealed 
that  recommendations  for  materiel  changes  were  most  common.  In  an  analysis  of  fire 
support  deficiencies,  materiel  recommendations  were  offered  as  the  solution  to  15  of  the 
29  noted  deficiencies.  [Ref.  60]  Another  Mission  Area  Analysis  for  assault 
support  recommended  materiel  changes  as  at  least  part  of  their  proposed  solutions  to  22 
out  of  28  priority  deficiencies.  [Ref.  61] 

The  possibility  of  an  equipment  or  materiel  orientation  is  not  surprising. 
The  requirement  for  Mission  Area  Analyses  has  its  roots  in  the  Office  of  Manpower  and 
Budget  (OMB)  Circular  A- 109  which  requires  any  major  new  system  acquisition  be 
preceded  by  an  analysis  of  the  mission.   [Ref.  62]     Mission  Area  Analyses  were 
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intended  from  the  very  beginning  to  provide  evidence  to  support  the  acquisition  of  new 
equipment. 

The  development  of  MTACCS  will  also  emphasize  materiel  and 
equipment  solutions.  MTACCS  will  not  change  the  organization  or  structure  of  the 
MAGTF.  Only  procedures  will  be  modified  to  some  extent  as  tasks  are  automated. 
[Ref.  32] 

b.      Basic  Recommendations 

A  second  trend  appears  to  be  that  the  recommendations  that  result  from 
the  combat  development  process  are  only  basic  recommendations  that  do  not  offer 
integrated  solutions.  A  basic  recommendation  may  only  address  one  element  of  the  entire 
system,  whereas  an  integrated  recommendation  might  address  a  requirement  for  changes 
in  several  elements  of  the  system.  A  "basic"  recommendation  for  a  communications 
deficiency,  for  example,  might  be  to  buy  another  radio.  An  "integrated"  recommendation 
might  be  to  adjust  procedures  to  cut  down  on  traffic  requirements,  reorganize  the  unit  to 
allow  for  alternate  communications  paths,  and  reallocate  traffic  to  alternative  systems. 
The  basic  recommendation  may  be  the  best  solution  at  times,  but  probably  not  all  the 
time.  The  recommendations  in  Mission  Area  Analyses  are  rarely,  if  ever,  as  involved  as 
the  example  of  an  "integrated"  recommendation  shown  here. 

The  process  shown  earlier  in  Figure  29  also  fosters  a  basic  approach  to 
solutions.  While  the  process  diagram  is  necessarily  simplified,  it  implies  that  solutions 
to  a  deficiency  can  be  categorized  as  either  training,  doctrine,  and  force  structure 
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recommendations  or  equipment  recommendations.  The  diagram  does  not  foster  the  idea 
of  integrated  solutions. 

In  some  sense,  MTACCS  is  a  basic  recommendation  as  well.  While  the 
integration  of  component  systems  will  be  enormously  complex,  the  underlying  concept 
is  relatively  basic:  automate  tasks  that  are  currently  being  done  by  manual  systems,  and 
allow  those  automated  systems  to  share  information.  No  attempt  will  be  made,  at  least 
initially,  to  modify  force  structure  or  doctrine  in  concert  with  materiel  procurement. 

2.      Command  and  Control  System  Trends 

The  development  of  command  and  control  systems  within  DOD  in  general  also 
appears  to  follow  certain  trends  that  are  described  here. 

a.      Use  of  an  "Applique  Approach  "  for  C2 

It  appears  to  be  a  general  trend  in  the  military  to  acquire  weapons  systems 
first  and  then  devise  the  command,  control,  and  communications  as  an  accessory 
[Ref.  63 :p  5].  This  method  of  development  has  been  referred  to  as  an  "applique 
approach"  [Ref.  64:p  17].  This  approach  can  be  sufficiently  effective  when  the 
complexity  of  the  system  is  relatively  low.  Command  and  control  of  what  essentially 
amounts  to  the  entire  Marine  Corps,  however,  is  not  low  on  the  complexity  scale. 

The  Strategic  Defense  Initiative  (SDI)  is  one  example  of  a  highly  complex 

system  with  software  challenges  of  unprecedented  magnitude.  In  addressing  the  command 

and  control  of  SDI,  one  report  stated: 

The  trade-offs  necessary  to  make  the  software  task  tractable  are  in  the  system 
architecture... the  "applique  approach"  of  designing  the  system  first  and  then  writing 
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the  software  to  control  it  is  the  wrong  approach  for  SDI.  System  architecture  and 
battle  management  must  be  developed  together.    [Ref.  63:p  v] 

The  MTACCS  program  appears  to  follow  an  applique  approach  as  well. 

The  MAGTF  structure,  doctrine,  and  communications  have  been  set  and  MTACCS 

hardware  and  software  will  be  applied  as  an  accessory.    As  with  SDI,  the  trade-offs 

necessary    to    make    software    development    more    manageable    might    be    found    in 

modifications  to  force  structure,  doctrine,  or  the  communications  architecture.  It  appears, 

however,  that  these  elements  of  the  Marine  Corps  system  will  not  budge. 

b.      Standardization  is  More  Important  than  Optimization 

In  the  age  of  a  seemingly  boundless  integration  of  transistors  onto  a  single 

chip,  merely  coping  with  technology  is  consuming  a  majority  of  our  efforts.  Many  in  the 

military  have  virtually  abandoned  the  idea  of  optimizing  and  are  now  simply  trying  to  get 

their  systems  to  work.    Lieutenant  Colonel  C.  Kenneth  Allard,  USAF,  emphasized  this 

point  in  his  book  Command,  Control,  and  the  Common  Defense: 

The  dominant  issue  in  establishing  a  telecommunications  path  is  not  its  optimization 
but  standardization  of  the  process.  More  important  than  doing  things  the  best  way 
is  doing  them  the  same  way.  [Ref.  30:p  17] 

MTACCS,  too,  may  suffer  from  this  plight.     The  challenge  of  "just 

getting  it  to  work"  is  enormous.  The  complexity  and  volume  of  interfaces  is  so  large,  that 

the  first  priority  appears  to  be  establishing  a  demonstration  model  to  field  a  limited 

capability.   Optimizing  appears  to  be  a  lesser  concern. 
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D.      A  DESCRIPTION  OF  SYSTEMS  ENGINEERING 

1.  Introduction 

Combat  Development  has  much  in  common  with  systems  engineering.  This 
section  develops  a  description  of  systems  engineering  to  serve  as  a  framework  for 
comparison. 

2.  Definition 

A  system  is  defined  as  a  collection  of  elements  organized  to  perform  a  set  of 
designated  functions  in  order  to  achieve  a  specific  result.  The  elements  which  comprise 
a  system  include  personnel,  material,  equipment,  facilities,  procedures,  and  information. 
The  approach  used  to  plan  and  design  a  system  in  its  entirety  is  called  systems 
engineering.  The  goal  of  systems  engineering  is  to  plan  and  design  a  system  as  an  entity 
in  order  to  satisfy  the  needs  of  the  user.  [Ref.  65]  Effective  systems  engineering 
makes  the  successful  operation  of  all  subparts  guarantee  that  the  assemblage  will  perform 
the  tasks  for  which  it  was  intended.  Many  systems  fail  to  accomplish  what  was  expected 
due  to  inadequate,  biased,  or  misleading  communications  between  the  system  designers 
and  the  users.  [Ref.  22:p  3] 

There  are  many  definitions  of  systems  engineering.  The  terms  "systems 
engineering"  and  "systems  engineering  management"  are  often  used  interchangeably  and 
the  difference  between  them  is  occasionally  blurred.  Systems  engineering  can  be  defined 
as  the  application  of  scientific  and  engineering  efforts  to: 
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1.  Transform  an  operational  need  into  a  description  of  system  parameters  and  a 
system  configuration  through  the  iterative  process  of  definition,  synthesis,  analysis, 
design,  test,  and  evaluation. 

2.  Integrate  related  technical  parameters  and  assure  compatibility  of  all  physical, 
functional,  and  program  interfaces  in  a  manner  which  optimizes  the  total  system 
definition  and  design. 

3.  Integrate  reliability,  maintainability,  safety,  survivability,  human  and  other  such 
factors  into  the  total  engineering  effort  to  meet  cost,  schedule,  and  technical 
performance  objectives.  [Ref.  66] 


The  Defense  Systems  Management  College  concentrates  on  management 
aspects  and  defines  systems  engineering  as  the  management  function  that  controls  the 
total  system  development  effort  for  the  purpose  of  achieving  an  optimum  balance  of  all 
system  elements.  It  is  a  process  which  transforms  an  identified  operational  need  into  a 
description  of  system  parameters  and  integrates  those  parameters  to  optimize  the  overall 
system  effectiveness.  [Ref.  67:p  1-2] 

For  the  purposes  of  this  thesis,  systems  engineering  is  composed  of  two 
elements,  the  engineering  process  and  the  management  of  the  overall  engineering  effort. 
The  systems  engineering  process  consists  of  the  steps  and  procedures  used  to  define, 
design,  and  develop  the  system.  Systems  engineering  management  consists  of  the 
activities  and  decisions  that  control  the  process  of  the  engineering  effort.  The  systems 
engineering  process  is  described  in  detail  in  the  following  sections.  It  is  this  description 
that  will  serve  as  a  basis  for  comparison  with  combat  development. 
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3.      The  Systems  Engineering  Process 

a.  Definition  of  the  Systems  Engineering  Process 

The  systems  engineering  process  is  oriented  toward  system  analysis, 
design,  and  definition.  A  sequential  process  is  depicted  in  Figure  30.  [Ref.  65: p  43]  This 
figure  represents  the  model  that  will  be  used  in  the  systems  engineering  assessment.  The 
process  is  defined  in  terms  of  tasks  to  be  performed  somewhat  sequentially. 

b.  A  Systems  Engineering  Process  Model 

The  systems  engineering  process  model  consists  of  the  steps  depicted  in 
Figure  30.  Each  step  has  several  functions  to  be  accomplished  before  the  next  step  can 
be  completed. 

(1)  Requirements  Analysis.  A  major  problem  with  many  systems  is  that 
the  reasons  to  build  the  system  do  not  necessarily  fill  operational  requirements.  The 
requirements  analysis  examines  the  current  threat  and  mission  needs.  Once  the  needs 
have  been  validated  to  meet  the  threat,  system  performance  requirements  are  defined. 
Utility  functions  are  created  to  provide  a  method  (a  value  system)  to  compare  disparate 
characteristics  of  different  systems  on  a  relatively  equal  basis.  The  choice  of  the  system 
to  pursue  is  decided  on  the  basis  of  a  weighted  decision  matrix.  Characteristics  are 
evaluated  and  weighted  and  each  system's  characteristics  are  measured.  The  alternatives 
with  the  highest  scores  are  considered  for  further  development.  This  is  the  key  step  of 
the  system  engineering  process:  translating  mission  requirements  into  system  performance 
and  design  requirements.  [Ref.  65] 
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Figure  30:  Systems  Engineering  Process  [Source:  Ref.  65] 
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(2)  Functional  Analysis.  Functional  analysis  is  a  method  for  analyzing 
performance  requirements  and  dividing  them  into  discrete  tasks  or  activities.  It  involves 
the  identification  and  decomposition  of  the  primary  system  functions  into  subfunctions 
at  ever  increasing  levels  of  detail  to  establish  a  baseline  of  the  functions  that  must  be 
performed  in  order  to  satisfy  system  requirements.  [Ref.  67:p  6-1] 

Three  levels  of  functional  decomposition  are  generally  performed  to 
provide  enough  description  to  suggest  alternative  architectures  for  evaluation.  Figure  3 1 
depicts  these  three  levels.  The  top  level  (level  0)  functional  flow  diagram  shows  a 
general  overview  of  the  activities  performed  during  the  mission.  The  second  level  (level 
1)  shows  the  functions  that  are  done  in  each  activity.  The  third  level  (level  2)  breaks 
down  in  greater  detail  the  actions  that  are  performed  for  each  function  in  level  1.  After 
a  concept  has  been  chosen,  the  functional  decomposition  will  be  broken  down  further  to 
reflect  a  particular  design.  [Ref.  65 :p  21] 

(3 )  Definition  of  System  Alternative  Architectures.  An  architecture  is 
a  statement  of  what  is  required  to  accomplish  the  mission.  The  statement  includes  the 
hardware,  software,  personnel,  and  operational  items  to  be  used.  'It  is  the  allocation  of 
system  functions  among  defined  system  elements."  [Ref.  65:p  23] 

Since  there  are  a  number  of  ways  to  accomplish  the  same  task  using 
different  technologies,  procedures,  or  equipment,  a  study  of  several  different  methods 
must  be  accomplished  to  determine  the  optimal  solution.  This  study  must  measure  each 
individual  system,  on  its  own  merits,  in  the  accomplishment  of  the  requirements. 
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Figure  31:  Functional  Decomposition  [Source:  Ref.  67] 
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Normally    this    would    be    accomplished    through    a    value    system    of   some    kind. 
[Ref.  65:p  24] 

(4)  Concept  Evaluation  and  Selection.  There  are  three  steps  to  concept 
evaluation  and  selection.  The  first  is  to  synthesize  and  refine  the  alternative  architectures 
through  a  series  of  trade  studies.  The  second  step  is  concept  selection.  Based  on  the 
results  of  the  trade  studies  and  the  weighted  decision  criteria  described  in  the 
requirements  analysis,  the  most  promising  system  or  concept  is  selected  for  further 
development.  The  results  from  the  trade  studies  and  the  utility  functions  consisting  of  the 
decision  criteria  should  have  sensitivity  analysis  conducted  for  each  system  or  concept. 
Small  changes  in  performance,  especially  when  the  final  scores  are  close,  may  change  the 
optimal  solution.  A  review  of  the  scores  will  usually  reveal  a  few  key  decision  criteria 
that  drive  concept  selection.  [Ref.  65 :p  30] 

The  final  step  is  concept  definition.  Concept  definition  takes  the 
selected  concept  and  formally  defines  its  performance,  physical  configuration,  and  critical 
technologies.  Performance  parameters,  error  budgets,  hardware  and  software 
specification,  and  human  and  machine  interfaces  are  some  examples  of  the  areas  that 
contribute  to  the  system's  composition.  Human  factors  engineering  must  play  a  vital  role 
to  ensure  the  system  can  be  operated  effectively,  especially  during  periods  of  high  stress. 
Survivability,  maintainability,  and  availability  criteria  are  delineated  at  this  point.  The 
final  part  of  concept  definition  is  a  systems  engineering  management  schedule  with 
milestone  decision  points.  [Ref.  65:p  30-35] 


156 


(5)  Concept  of  Operations  The  Concept  of  Operations  is  written  by  the 
operational  using  command.  It  consists  of  a  time  sequenced  narrative  of  system 
operations,  system  employment  and  deployment,  and  system  readiness.  [Ref.  65:p  35-36] 

E.       A  SYSTEM  VIEW  OF  THE  MARINE  CORPS 

The  Marine  Corps  is  a  highly  complex  organization;  a  "Band  of  Brothers"  bound 
by  tradition,  esprit  de  corps,  honor,  loyalty,  and  patriotism.  A  system  view  of  the  Marine 
Corps  can  not  provide  a  complete  portrayal  of  the  intricacies  of  America's  warrior  elite. 
It  is  useful  and  necessary  for  the  purpose  of  this  assessment,  however,  to  reduce  the 
complexities  of  combat  development  to  a  manageable,  simple  representation.  There  are 
several  ways  to  represent  combat  development  in  varying  levels  of  detail.  The  alternative 
chosen  in  this  assessment  is  to  view  the  entire  Marine  Corps  as  an  enormous  "system" 
designed  to  develop  combat  power  and  efficiently  translate  that  power  when  necessary 
into  combat  force  effectiveness.  The  system  is  composed  of  Marines  and  their 
organizations,  weapons  and  equipment,  and  procedures  and  standards. 

Headquarters  Marine  Corps,  the  Marine  Corps  Combat  Development  Command,  and 
the  Marine  Corps  Research,  Development,  and  Acquisition  Command  together,  essentially 
serve  as  the  systems  engineering  team  for  the  Marine  Corps.  They  manage  the  total 
system  development  effort  within  the  Marine  Corps  to  achieve  an  effective  balance  of  all 
system  elements.  That  balance  is  optimal  when  the  combat  effectiveness  of  the  Corps  is 
maximized  within  given  resource  constraints.   The  organization  and  procedures  used  to 
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achieve  that  optimal  balance  are  absolutely  vital  to  the  success  and  future  of  the  Marine 
Corps. 

Essentially,  MCCDC  serves  as  the  systems  engineer  for  the  Marine  Corps.  The 
Commanding  General  of  MCCDC  has  been  assigned  the  responsibility  of  ensuring  that 
the  Marine  Corps  functions  smoothly  as  an  effective,  integrated  system  and  can 
accomplish  its  assigned  missions. 

In  many  respects,  MCCDC  carries  out  a  systems  engineering  process  in  the 
development  of  concepts  and  requirements. 

In  a  very  basic  sense,  MCRDAC  serves  as  the  systems  engineering  management 
team  for  the  Marine  Corps.  The  Commanding  General  of  MCRDAC  has  been  designated 
as  the  Program  Executive  Officer  (PEO)  for  the  Marine  Corps.  As  such,  he  has  the 
responsibility,  authority,  and  accountability  for  all  Marine  Corps  acquisition  programs. 

Basically  MCRDAC  carries  out  a  systems  engineering  management  process  in  the 
development  of  systems  that  are  components  of  the  overall  Marine  Corps  "system". 

F.  THE  IMPACT  OF  APPLYING  SYSTEMS  ENGINEERING  TO  COMBAT 
DEVELOPMENT 

Applying  a  more  rigorous  scientific  methodology  to  combat  development  has  both 
positive  and  negative  aspects. 

1.      Positive  Aspects 

If  systems  engineering  is  properly  applied  to  combat  development,  several 
potential  benefits  exist.    The  most  important  benefit  could  be  a  more  effective  Marine 
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Corps;  a  Marine  Corps  that  is  capable  of  achieving  a  greater  level  of  combat  effectiveness 
within  the  same  resource  constraints.  This  greater  effectiveness  would  be  the  result  of 
attempts  at  balancing  all  of  the  elements  of  the  system  to  maximize  overall  combat 
effectiveness.   The  trends  mentioned  earlier  could  be  mitigated  or  eliminated  entirely. 

An  effective  systems  engineering  methodology  would  also  promote  the  idea 
of  examining  other  elements  of  the  system  as  potential  solutions  to  any  identified 
deficiencies.  In  the  MTACCS  program,  for  example,  software  development  is  seen  as  a 
significant  challenge.  One  hypothetical  method  of  reducing  the  software  complexity  can 
be  found  in  altering  force  structure  or  procedures.  In  this  example  then,  the  difficulty  in 
implementing  the  equipment  portion  of  the  overall  solution  is  lessened  through  the 
implementation  of  change  in  other  elements  of  the  system. 

2.      Negative  Aspects 

Negative  aspects  include  the  likelihood  of  a  lengthier  and  more  costly  combat 
development  process.  Complex  "integrated"  recommendations  would  be  far  more  difficult 
to  generate,  evaluate,  and  validate.  Considerable  resistance  to  changes  in  doctrine  and 
structure  is  almost  a  certainty.  In  addition,  "integrated"  recommendations  have  the 
appearance  of  the  "big  system  approach."  While  "big  system  approach"  has  no  formal 
definition,  it  appears  to  consist  of  two  aspects.  The  first  is  an  emphasis  on  complete 
development  of  a  fully  functioning  system  in  one  big  step.  The  second  aspect  involves 
simultaneous  modifications  to  several  elements  of  the  system.  The  MIFASS  program,  for 
example,  intended  to  implement  significant  modifications  to  doctrine,  equipment,  and 
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procedures  all  at  the  same  time.  The  experience  of  the  MIFASS  system  has  brought  great 
disfavor  on  "big  system  approaches"  that  affect  many  facets  of  the  Marine  Corps  system. 

G.      CONCLUSIONS 

1.  Little  Faith  in  the  "Big  System  Approach" 

The  failure  of  MIFASS  has  caused  the  Marine  Corps  to  have  little  faith  in  the 
"big  system  approach."  This  is  unfortunate  because  it  appears  that  the  chosen  alternative 
is  a  tendency  toward  evolutionary  development  of  only  one  element  of  the  Marine  Corps 
system  at  a  time:  change  some  equipment,  for  example,  and  keep  all  other  system 
elements  relatively  static.  The  trend  towards  evolutionary  development  appears  to  be 
beneficial;  whereas  the  reliance  on  basic  solutions  that  address  only  equipment,  for 
example  does  not.  While  basic  solutions  are  less  complex,  they  trade  a  great  deal  of 
effectiveness  away  to  achieve  that  lower  level  of  complexity.  Regardless  of  the  bad 
experience  of  MIFASS,  there  remains  a  need  to  implement  change  in  a  manner  that 
integrates  all  of  the  elements  of  the  system. 

2.  The  Need  for  Systems  Engineering  in  the  Marine  Corps 

As  described  earlier,  the  Marine  Corps'  "system"  is  composed  of  three  basic 
elements:  people  and  organizations,  weapons  and  equipment,  and  procedures  and 
standards.  Ideally,  these  elements  are  optimally  proportioned  and  structured.  Manpower 
levels,  types  and  quantities  of  equipment,  operating  procedures,  and  such,  have  been 
carefully  chosen  to  maximize  the  overall  effectiveness  of  the  system  within  the  resource 
constraints  imposed. 
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Revolutionary  advances  in  any  one  of  the  elements  can  dramatically  improve 
system  effectiveness,  but  the  new  proportion  or  structure  may  no  longer  be  optimal. 
Modifications  to  doctrine,  procedures,  or  force  structure,  for  example,  may  better 
complement  a  major  advance  in  weapons  technology  that  the  current  doctrine,  procedures, 
or  force  structure.  If  no  complementary  modifications  are  made,  effectiveness  may  be 
less  than  the  maximum  possible  within  a  given  level  of  resources.  This  equates  directly 
to  wasted  resources.  In  some  cases,  advances  in  one  element  may  even  be  countered  by 
out  of  date  practices  in  another  element. 

In  recent  years,  revolutionary  advances  have  occurred  most  often  in  the 
development  of  weapons  and  equipment.  Users  and  developers  alike  are  tempted  to  solve 
most  deficiencies  with  new  technology.  New  technology  alone,  however,  focuses  on  only 
one  element  of  a  complex  system.  Equal  attention  must  be  given  to  all  elements  of  the 
system  to  ensure  optimal  use  of  resources. 

Robert  Everett  also  believed  that  new  technology  should  not  merely  be  used 

to  support  a  static  organizational  structure.    Addressing  the  role  of  technology  in  the 

organization,  Everett  wrote: 

The  problem  with  the  staff  is  not  how  to  support  the  staff,  but  how  to  get  rid  of  the 
staff....  [Ref.  40:p  24].  To  take  advantage  of  distributed  C3  we  must  learn  how  to 
distribute  the  staff  function  itself,  how  to  separate  the  peacetime  from  the  wartime, 
and  how  to  use  computers  to  support  the  commander  directly  rather  than  the 
commander's  staff....  Much  work  needs  to  be  done  on  finding  ways  to  replace  all 
kinds  of  people  with  machines  in  carrying  out  C3  functions.  [Ref.  40:p  23] 

Clearly  Everett  promotes  the  simultaneous  evolution  and  integration  of  staff 

(Marines  and  their  organizations),  procedures,  and  technology  (weapons  and  equipment). 
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In  managing  the  Marine  Corps  as  an  enormous  system,  the  systems  engineering  team 
must  employ  a  scientific  approach  in  order  to  efficiently  maximize  combat  effectiveness. 
The  Marine  Corps  must  evolve  continuously  using  these  scientific  methods  as  tools  to 
direct  its  own  evolution. 

3.      The  Impact  of  Continuous  Evolution 

Continually  balancing  the  elements  of  the  system  implies  a  continual 
reorganization.  Frequent  reorganization,  however,  is  viewed  by  most  Marines  as  more 
of  a  malady  itself  than  as  a  cure  for  effectiveness  shortfalls.  When  the  "spectre"  of 
reorganization  raises  its  ugly  head,  few  embrace  it  with  enthusiasm.  It  is  true  that 
reorganization  and  changes  in  doctrine  can  disrupt  the  continuity  within  a  command  and 
degrade  performance,  at  least  initially.  Changes  such  as  these  are  frequently  cited  reasons 
for  a  lack  of  cohesion  within  a  unit. 

Marines,  like  everyone  else,  are  creatures  of  habit;  more  comfortable  with 

routine  than  chaos.  Adaptability  and  flexibility,  however,  are  vital  to  the  success  of  the 

Corps.       In    the    midst    of   revolutionary    advances    in    weapons,    computers,    and 

communications,  the  remaining  elements  of  the  system  cannot  remain  static.  They  must 

keep  pace.    In  reflecting  on  the  relationship  of  technology  to  command  in  his  book 

Command  in  War,  Martin  Van  Creveld  wrote: 

...  The  most  important  conclusion  of  this  study  may  be  that  there  does  not  exist,  nor 
has  there  existed,  a  technological  determinism  that  governs  the  method  to  be 
selected  for  coping  with  uncertainty.  At  various  periods  in  history,  and  in  the  face 
of  any  one  set  of  requirements  arising  from  the  art  of  war  as  exercised  in  those 
periods,  different  military  organizations,  though  making  use  of  the  same  general 
communications  and  data  processing  capability,  have  approached  the  problem  from 
radically  different  angles  with  radically  different  results.  There  was  nothing  in  the 
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nature  of  any  single  technology,  whether  based  on  the  signum  or  on  the  telephone, 
the  messenger  or  the  computer,  to  dictate  which  of  two  solutions  should  be  adopted. 

Far  from  determining  the  essence  of  command,  then,  communications  and 
information  processing  technology  merely  constitutes  one  part  of  the  general 
environment  in  which  command  operates.  To  allow  that  part  to  dictate  the  structure 
and  functioning  of  command  systems,  as  is  sometimes  done,  is  not  merely  to 
become  the  slave  of  technology  but  also  to  lose  sight  of  what  command  is  all  about. 
Furthermore,  since  any  technology  is  by  definition  subject  to  limitations,  historical 
advances  in  command  have  often  resulted  less  from  any  technological  superiority 
that  one  side  had  over  the  other  than  from  the  ability  to  recognize  those  limitations 
and  to  discover  ways  -  improvements  in  training,  doctrine,  and  organization  -  of 
going  around  them.  Instead  of  confining  one's  actions  to  what  available  technology 
can  do,  the  point  of  the  exercise  is  precisely  to  understand  what  it  cannot  do  and 
then  proceed  to  do  it  nevertheless.  [Ref.  40:p  274-275] 

4.      The  Point  of  This  Chapter 

The  principle  theme  of  this  chapter  is  this:  while  technology  is  capable  of 

marvelous  achievements,  it  continues  to  be  only  a  part  of  a  larger  system.    To  make 

optimal  use  of  technology  does  not  necessarily  maximize  the  effectiveness  of  the  system 

as  a  whole.  Each  element,  the  personnel,  procedures,  and  technology,  of  the  system  must 

be  properly  balanced  to  achieve  that  maximum  effectiveness.  In  his  book  Technology  and 

War.  Martin  Van  Creveld  wrote: 

...  let  us  turn  to  the  first  paragraph  on  the  first  page  in  the  first  chapter  of 
Clausewitz's  On  War.  Here,  armed  conflict  is  defined  as  an  act  of  violence  where 
each  side  is  out  to  destroy  the  other.  This  makes  it  into  the  province  of  hardship 
and  of  suffering,  of  stress  and  fear,  and  pain  and  death.  ...  war  is,  therefore, 
primarily  an  affair  of  the  heart.  It  is  dominated  by  such  irrational  factors  as 
resolution  and  courage,  honor  and  duty  and  loyalty  and  sacrifice  of  self.  When 
everything  is  said  and  done,  none  of  these  have  anything  to  do  with  technology... 
so  it  was  at  a  time  when  war  was  limited  to  face  to  face  clashes  between  hide-clad, 
club-armed  cavemen  50,000  years  ago;  so  it  will  be  when  laser  firing  flying  saucers 
permit  it  to  be  fought  over  interplanetary  distances  100,  or  500,  or  1,000  years 
hence.  [Ref.  68:p  313-314] 
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Adherence  to  a  systems  engineering  process  in  combat  development  has  the 
potential  of  mitigating  some  of  the  current  trends  and  restoring  the  oft  neglected  elements 
of  the  system  to  their  proper  levels  of  emphasis.  The  trend  toward  an  equipment 
orientation,  for  example,  can  be  lessened  if  modifications  to  doctrine,  force  structure, 
procedures,  and  such,  are  more  readily  accepted  as  candidate  solutions. 
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Vn.  MTACCS  INTEROPERABILITY  ASSESSMENT 

A.      INTRODUCTION 

1.  Objective 

The  purpose  of  this  chapter  is  to  describe  the  problems  encountered  in 
achieving  interoperability  in  past  programs  and  assess  the  direction  MTACCS  is  taking 
towards  interoperability. 

2.  Methodology 

From  the  very  beginning,  the  developers  of  MTACCS  have  encountered  great 
difficulty  in  their  efforts  to  obtain  interoperability  among  the  MTACCS  subsystems.  This 
chapter  begins  with  a  review  of  the  interoperability  problems  of  the  past  and  then  follows 
with  a  description  of  the  current  efforts  to  enhance  interoperability.  It  then  concludes 
with  an  assessment  of  those  efforts. 

3.  A  History  of  Interoperability  Problems 

a.      Historical  Reasons  for  Interoperability  Problems 

(1)  Management  Redundancy.  Historically,  the  Department  of  Defense 
has  tasked  numerous  agencies  and  organizations,  as  shown  in  Figure  32,  with  the 
development  of  interoperability  standards.  This  has  led  in  some  cases  to  ambiguities  in 
responsibility  and  authority  for  standards.  There  is  no  "czar"  that  could  manage 
interoperability.     There  is  a  forum,  the  Military  Communications-Electronics  Board 
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Figure  32:  Organizations  involved  in  Interoperability  [Source:  Ref.  69] 

(MCEB),  at  which  many  of  the  key  organizations  meet.    However,  this  board  is  not 

equipped  to  resolve  interoperability  issues  in  a  timely  fashion.    The  Joint  Tactical  C3 

Agency  (JTC3A)  was  established  to  enhance  interoperability  at  the  theater/tactical  level. 

The  JTC3A,  however,  mat  not  be  an  effort  of  sufficient  strength.  Dr.  Stuart  Starr  of  the 

MITRE  Corporation  has  written: 

(JTC3A)  has  limited  influence,  is  under-resourced,  and  tends  to  be  reactive  rather 
than  proactive...  The  key  role  in  interoperability  management  devolves  to  the 
Service  Program  Executive  Officers  (PEO's)  and  the  Program  Managers  (PM). 
[Ref.  69:p  5-6] 
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In  a  few  large  scale  programs33,  such  as  NIS,  WIS,  and  TRI-TAC, 
attempts  were  made  to  consolidate  authority  and  centralize  development  in  an  effort  to 
coordinate  interoperability.  Although  the  performance  of  these  organizations  varied,  there 
were  several  areas  of  relative  consistency.  In  general,  the  organizations  were  too  slow, 
too  expensive,  and  resulted  in  little  success.  [Ref.  71:p  8] 

Since  there  is  no  central  organization  to  establish  DOD 
interoperability  standards  that  are  directive  in  nature,  the  responsibility  for  interoperability 
falls  on  the  program  manager.  However,  the  program  manager  tends  to  be  narrowly 
focused  and  the  top  priorities  for  many  programs  have  been  performance,  schedule,  and 
cost.  Little  effort  has  been  expended  to  design  interoperability  into  a  program  at  its 
inception.  Insufficient  effort  has  been  made  to  coordinate  cross  program  adjustments 
when  configuration  changes  were  made.  Proper  emphasis  has  not  been  given  to 
interoperability.  [Ref.  69:p  8] 

(2)  Architectural.  C3  systems  are  characterized  by  many  interfaces  that 
are  complex,  frequently  changing,  difficult  to  predict,  and  occupy  many  levels.  A  broad 
architectural  vision  must  be  established  early  to  achieve  and  maintain  interoperability. 
This  vision  must  state  clearly  the  relationship  between  systems.  In  the  past  there  has  been 


The  NATO  Identification  System  (NIS)  is  developing  the  next  generation  query 
and  response  system  to  support  NATO's  need  for  interoperable  target  identification 
capability.  The  World  Wide  Military  Command  and  Control  System  (WWMCCS) 
Information  System  (WIS)  was  to  modernize  key  facets  of  WWMCCS.  TRI-TAC  was 
chartered  to  develop  a  family  of  interoperable  communications  systems  for  the  military. 
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no  vision  and  architectures,  if  developed,  were  generally  not  continually  adhered  to. 
[Ref.  69:p  6] 

MIFASS,  for  example,  had  a  very  general  vision  and  did  not  adhere 
to  the  stated  architecture.  When  changes  to  the  architecture  were  made,  there  was  little 
coordination  among  the  other  MTACCS  subsystems. 

(3)  Proliferation  of  Standards.  In  order  to  be  interoperable,  the  system 
must  be  configured  to  a  single  set  of  compatible  standards.  Currently,  there  are  several 
agencies  and  directives  developing  and  setting  standards.  This  makes  it  difficult  to 
determine  the  proper  set  of  standards  and  building  to  "a"  standard  does  not  necessarily 
guarantee  interoperability.  [Ref.  71:p  8] 

(4)  The  Expense  of  Backward  Compatibility  with  Fielded  Systems. 
Backward  Compatibility  entails  enabling  the  system  to  be  interoperable  with  older,  fielded 
systems.  Interoperability  can  be  achieved  through  any  suitable  method,  and  need  not  be 
restricted  to  technological  changes.  These  older  systems  usually  utilize  outdated 
technology,  behind  that  being  fielded  in  the  new  system.  The  Department  of  Defense  has 
already  invested  an  immense  amount  of  money  in  C2  system  development  and  fielded  a 
number  of  systems.  Achieving  backward  compatibility  can  be  extremely  difficult  and 
expensive.  In  addition,  there  are  many  unique  systems  within  the  different  services. 
Because  of  their  unique  nature,  these  systems  tend  to  be  limited  in  their  capability  to 
interoperate  with  other  systems.  [Ref.   71:p  8] 


168 


(5)  Lack  of  Standard  Testing  Policy.  Another  common  source  of 
interoperability  problems,  is  the  manner  in  which  systems  are  tested.  As  depicted  in 
Figure  33,  each  service  maintains  testing  agencies  of  its  own.  Additionally,  many  civilian 
testing  and  verification  agencies  and  contractors  are  also  used.  There  does  not  seem  to 
be  a  central  manager  or  overseer  who  can  direct  testing  efforts  in  a  singular  direction  nor 
is  there  a  central  repository  of  interoperability  standards  and  information  to  serve  as  a 
baseline  for  testing.  [Ref.  69:  p  8] 


(natcT) 


Figure  33:  Test  Facilities  [Source:  Ref.  69] 
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b.      Examples  of  Prior  Interoperability  Problems 

It  has  been  noted  previously  that  MTACCS  was  originally  conceived  as 
a  "conceptual  association"  of  systems.  That  definition,  combined  with  weak  configuration 
management,  bred  interoperability  problems  of  immense  proportions.  The  problem  was 
particularly  acute  in  the  MIFASS  program.  By  1987,  the  Institute  for  Defense  Analyses 
declared  that  "MIFASS  would  have  little  commonality  with  any  other  MTACCS  system." 
[Ref.  12:p  E-20]  The  development  of  protocols  for  the  Unit  Level  Message  Switch34 
(ULMS),  for  example,  was  neither  coordinated  with  MIFASS  nor  with  the  other  systems 
it  was  to  support.  MIFASS  was  developed  with  different  message  protocols  and  was 
incompatible  with  the  ULMS.  MIFASS  was  also  incompatible  with  both  the  Position 
Location  Reporting  System  (PLRS)  and  the  Digital  Communications  Terminal  (DCT). 
Work  around  solutions  were  required  in  order  to  provide  common  modes  of  operation. 
[Ref.  43:p  31] 

B.      INTEROPERABILITY 

1.      Definition  of  Interoperability 

As  defined  in  JCS  Pub  1-02,  interoperability  is: 

...  the  capability  of  systems,  units,  or  forces  to  provide  services  to,  and  accept 
services  from  other  systems,  units,  or  forces,  and  to  use  the  services  so  exchanged 
to  enable  them  to  operate  effectively  together.  It  is  achieved  among 
communications-electronics  equipment  when  information  or  services  can  be 
exchanged  directly  and  satisfactorily  between  equipment  and/or  users. 
[Ref.  70:p  190] 


The  primary  switching  device  for  message  transmission  between  command  and 
control  centers. 
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In  simpler  terms,  interoperability  is  the  ability  to  exchange  data  in  a  prescribed 
manner  and  to  use  extracted  information  from  that  data  to  operate  together  effectively 
[Ref.  71:p  3].  The  information  that  is  passed  must  be  understandable  to  the 
receiver. 

Interoperability  can  be  achieved  through  manual  or  automated  methods.  It  can 
be  designed  into  a  system  from  inception  or  added  as  an  applique  after  the  system  is 
fielded.  Designed-in,  automated  interoperability  requires  that  emphasis  be  placed  in  the 
four  basic  elements  of  interoperability. 

2.      Elements  of  Interoperability 

There  are  four  basic  elements  in  achieving  automated  interoperability. 


1.  Technical  Interface  Standards.  These  involve  the  "electrical  engineering"  aspects 
of  the  problem.  This  includes  the  interfaces  among  the  data  systems,  modems, 
and  receivers/transmitters  as  well  as  the  waveforms  and  modulation  designs. 

2.  Message  Standards.  These  are  the  data  elements,  data  items,  and  individual 
message  formats  in  which  data  is  to  be  transmitted  between  operators. 

3.  Operating  Procedures.  These  refer  to  the  procedures  to  be  followed  by  data 
system  operators  in  the  establishment  of  data  links  and  exchange  of  tactical  data. 
These  procedures  should  not  be  confused  with  the  broader  set  of  operational 
procedures  that  guide  tactical  actions. 

4.  Database  and  Applications  Program  Standards.  These  define  variable  formats  that 
represent  information  that  is  stored  and  processed  in  the  system.  [Ref.  69: p  2] 


As  depicted  in  Figure  34,  the  four  elements  must  be  negotiated  between 
programs.  In  addition  to  the  four  elements  listed  above,  thoroughly  tested  configurations, 
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Figure  34:  Elements  of  Automated  Interoperability  [Source:  Ref.  69] 
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well  trained  operators,  and  configuration  control  (or  management)  of  interfaces,  are 
required  to  achieve  interoperability.  [Ref.  71:p  4] 

3.      Methods  of  Interoperability 

The  level  of  interoperability  sought  should  be  derived  from  careful  assessment  of 
the  potential  benefits  and  liabilities  based  on  a  broad  and  deep  understanding  of 
mission  needs  and  program  constraints.  [Ref.  69:p  5] 

Figure  35  depicts  four  of  the  five  basic  methods  of  interoperability.  These 
methods  describe  ways  to  achieve  a  level  of  automated  or  manual  interoperability.  Any 
one  of  these  methods  can  be  the  "best"  solution  for  the  situation,  depending  on  the  needs, 
goals,  and  resources  available. 

The  "swivel  chair"  and  liaison  team  methods  are  quick,  flexible,  and  initially, 
relatively  inexpensive.  These  are  generally  best  in  temporary  situations  when 
organizations  who  normally  do  not  work  together  are  forced  to  interoperate  during  a 
conflict  or  exercise.  Common  modes  and  gateways  are  more  "after  the  fact" 
interoperability  fixes.  These  methods  are  generally  applied  to  systems  that  are  well  along 
in  their  development  or  are  actually  fielded.  Same  system  interoperability  is 
accomplished  in  the  design  and  development  of  a  system.  They  are  designed  with  the 
elements  of  interoperability  being  compatible.  It  is  important  to  keep  in  mind  that  100% 
interoperability  with  everyone  is  neither  achievable  nor  necessary.  The  disparity  in 
methods,  systems,  and  political  preference  is  a  challenging  obstacle  to  overcome  when 
determining  the  appropriate  level  of  interoperability. 
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Figure  35:  Methods  of  Interoperability  [Source:  Ref.  69] 

a.      "Swivel  Chair"  Interoperability 

The  "swivel  chair"  is  nothing  more  than  a  human  translator  between  two 
incompatible  systems.  Figure  35  shows  a  person  receiving  information  on  one  system  and 
sending  it  out  on  another  [Ref.  71:  5].  This  method  is,  as  one  can  imagine,  quite  slow 
and  prone  to  errors.  However,  it  is  inherently  the  most  flexible.  The  individual  only 
needs  to  know  how  to  read  information  from  one  system  and  input  the  information  into 
another  system.  The  need  for  "swivel  chair"  interoperability  can  occur  due  to 
incompatibility  in  any  one  of  the  elements  of  interoperability.  The  "swivel  chair"  method 
puts  a  heavy  burden  on  training,  and  personnel  assets,  and  compounds  configuration 
management  problems.  The  "swivel  chair"  method  was  used  in  Operation  Urgent  Fury 
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and  Golden   Pheasant  due   to   the   incompatibility   of  the   cryptographic   devices   to 
intemperate  with  all  of  the  others.  [Ref.  69: p  7] 

b.      Liaison  Teams 

Interoperability  can  be  achieved  through  the  use  of  liaison  teams. 
Although  not  depicted  in  Figure  35,  liaison  teams  are  very  similar  in  operation  to  the 
"swivel  chair".  Each  system  uses  a  human  translator  to  put  data  into  the  proper  format. 
The  advantage  of  liaison  teams  is  that  there  is  someone  to  help  interpret  the  data  from  the 
sending  organization.  There  are  many  instances  in  which  organizations  must  be  able  to 
exchange  information  rapidly  and  with  great  accuracy  while  possessing  separate, 
independent  systems  that  are  not  interoperable.  This  occurs  when  two  forces  must 
temporarily  work  together  to  achieve  a  common  goal,  such  as  in  Operation  Desert  Storm. 
The  Allied  coalition  in  that  operation  was  comprised  of  many  countries,  several  of  which 
had  never  conducted  combined  operations  with  many  of  the  other  forces  present.  Liaison 
teams  were  used  to  overcome  many  interoperability  problems.  Under  these 
circumstances,  liaison  teams  and  their  equipment  are  exchanged  between  organizations 
or  forces,  to  allow  the  exchange  of  intelligible  information,  and  to  achieve  at  least  a 
limited  amount  of  interoperability.  This  allows  each  organization  to  coordinate  with  one 
of  their  "own"  and  have  direct  interface  with  the  command  element  of  the  original 
organization. 

The  liaison  team  can  greatly  assist  in  the  understanding  of  the  capabilities 
and  limitations  of  his  forces.  Generally,  the  richness  of  information  provided  by  a  liaison 
team  far  exceeds  that  of  automated  methods.    Forces  that  have  never  worked  together 
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before  or  were  not  intended  to  work  together,  generally  require  this  high  level  of  richness 
of  information. 

c.  Use  of  Common  Modes 

Figure  35  shows  two  different  systems  interoperating.  Even  though  the 
systems  are  different,  they  have  achieved  partial  automated  interoperability  through 
agreement  in  the  four  necessary  elements  described  earlier.  Generally,  this  is  "partial" 
interoperability  with  each  system  having  some  common  modes  with  the  other  system.  In 
this  approach,  it  is  common  to  have  only  a  very  austere  interoperability  capability.  Both 
systems  use  compatible  communications  interface  standards,  message  standards,  operating 
procedures,  and  database  and  applications  standards.  This  method  requires  increased 
testing  to  ensure  interoperability.  The  training  and  configuration  problems  can  also 
increase  due  to  dissimilarities  in  the  physical  hardware  and  software.  [Ref.  71:p  5] 

d.  Use  of  a  Gateway 

Two  dissimilar  systems  can  be  made  interoperational  through  the  use  of 
a  gateway.  This  time  there  is  an  electronic  translator  that  uses  hardware  and  software  to 
translate  one  system's  information  into  a  format  that  is  understandable  to  the  other.  As 
with  the  "swivel  chair"  method,  neither  system  needs  to  have  all  the  elements  in  common 
with  the  other  system.  [Ref.  71  :p  5] 

Although  faster  and  more  accurate  than  the  swivel  chair,  there  are 
limitations  to  how  much  a  gateway  can  do.  Only  certain  standards  can  be  translated,  for 
example.   From  a  training  standpoint,  the  gateway  would  be  transparent  to  the  user,  but 


176 


the  system  manager/maintainer  would  need  increased  training  to  handle  the  operation  of 
the  gateway.  Configuration  management  may  be  easier  depending  on  the  capability  of 
the  gateway.  The  more  capable  the  gateway  and  the  more  protocols  and  standards  it  call 
handle,  the  easier  the  configuration  management  due  to  the  increased  flexibility. 
[Ref.  72] 

e.      Use  of  the  Same  System 

As  shown  in  Figure  35,  using  the  same  system  is  a  reliable  method  of 
achieving  automated  interoperability.  Each  system  would  have  the  same  interface, 
message,  operating,  and  data  standards  as  the  rest  of  the  systems.  The  training  would  be 
the  same  for  each  user,  and  the  configuration  management  would  entail  configuring  only 
one  system.  [Ref.  71:p  5] 

4.      Steps  to  Achieving  Interoperability 

Figure  36  shows  a  pictorial  representation  of  the  basic  steps  to  achieving 
automated  interoperability.  The  steps  put  into  action  the  elements  of  interoperability  and 
demonstrate  a  sequence  for  minimizing  problems.  The  feedback  loops  highlight  the 
extensive  amount  of  time  and  coordination  that  must  take  place.   The  steps  include: 


1.  Establishing  System  Requirements.  These  requirements  must  be  based  on  a 
mission  perspective.  These  should  be  recorded  in  a  Technical  Interface  Concepts 
Document. 

2.  Develop  and  Specify  Standards.  These  include  message,  interface,  and 
database/applications  programs.  These  should  be  captured  in  a  Technical  Interface 
Design  Plan. 
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Architectural  vision: 
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Figure  36:  Steps  to  Interoperability  [Source:  Ref.  69] 


3.  Specification  of  Operating  Procedures.    These  include  the  interface  operating 
procedures,  the  establishment  of  data  links,  and  methods  of  exchanging  data. 

4.  Development  of  Interfaces.  These  are  the  individual  system  interfaces. 

5.  Test  of  Interface.     This  includes  the  development  and  implementation  of  an 
Interface  Test  Plan. 

6.  Training.     This  is  the  operational  training  of  the  operators  to  ensure  their 
proficiency  in  establishing  links  and  exchange  of  data. 

7.  Fielding. 

8.  Control  of  Configuration.  This  is  managing  and  controlling  the  interfaces  when 
the  system  becomes  operational  to  ensure  continued  interoperability.  [Ref.  69] 
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5.      Benefits  and  Liabilities  of  Interoperability 

Interoperability  yields  many  benefits,  but  not  without  a  price.     A  highly 
interoperable  system  suffers  from  liabilities  as  well.    Both  are  discussed  here. 

a.      Benefits 

(1)  Automated  Interoperability.  Many  of  the  benefits  are  obvious.  In 
particular,  the  minimization  of  errors  in  transmission  and  the  increased  speed  of 
information  processing  and  transmission  are  important  benefits.  There  will  be  reductions 
in  the  amount  of  people  necessary  to  perform  "translation"  services.  Interoperable 
systems  perform  without  the  need  for  data  to  be  massaged  into  new  formats. 
Maintenance  costs  are  reduced  due  to  a  limited  amount  of  diversity  in  equipment.  The 
equipment  is  all  physically  similar  and/or  operates  in  common  modes.  This  reduces  the 
amount  of  personnel,  training,  and  spare  parts  required  to  maintain  the  system.  [Ref.  69] 

(2)  Appropriate  Methods  of  Interoperability.  As  noted  above,  there  are 
some  obvious  benefits  to  automated  interoperability.  There  are,  as  well,  some  not  so 
obvious  benefits  of  interoperability  that  transcend  all  interoperability  methods.  In  general, 
interoperability  leads  to  each  unit  having  a  relatively  similar  perception  of  the  battle  and 
the  surrounding  environment.  This  can  lead  to  a  stronger  resistance  to  enemy  actions. 
Friendly  forces  reap  a  synergistic  benefit  from  working  together  without  wasting  effort 
or  resources  and  can  more  easily  reconfigure  around  a  destroyed  node  or  command  center. 
[Ref.  69] 
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b.      Liabilities 

(J )    Standardization  Makes  Things  Easier  for  the  Enemy.    In  his  book, 

Technology  and  War,  Martin  Van  Creveld  took  particular  care  to  point  out  the  liability 

of  standardization: 

However  desirable  or  necessary  (standardization)  may  be  from  the  point  of  view  of 
efficiency,  in  war  its  result  is  to  make  things  easy  for  the  enemy.  The  amount  of 
uncertainty  with  which  he  is  confronted  is  diminished.  He  is  put  in  a  position 
where  resources  and  attention  can  be  focused  on  countering  a  single  threat  instead 
of  many  different  ones.  Finally,  he  is  spared  the  dilemma  of  having  to  do  two 
contradictory  things  at  once;  which  probably  represents  the  most  important  single 
way  of  using  technology  (or  anything  else)  in  order  to  obtain  victory  in  war. 
[Ref.  68:p319] 

There  are  new  vulnerabilities  with  automated,  interoperable  systems. 

In  the  past,  a  software  virus  was  isolated  to  the  few  systems  it  could  effect.   Now,  with 

automated,  highly  interoperable  systems,  viruses  are  compatible  with  all  the  systems  and 

can  create  crippling  disruptions  in  vast  networks.  [Ref.  71:p  6] 

(2)    Integration  can  Diminish  the  Capability  of  the  System.   Despite  the 

fact  that  some  systems  can  achieve  "state  of  the  art"  levels  of  speed  and  efficiency,  they 

must  often  conform  to  interoperability  standards  which  direct  a  less  efficient  method  of 

operation  [Ref.  71].    These  operability  standards  usually  derive  from  older,  outdated 

systems  that,  with  today's  technological  pace,  are  nearing  obsolescence.   Although  this 

practice  may  be  more  cost  effective  in  the  short  term,  it  is  only  marginally  effective  in 

the  long  run.  [Ref.  39] 

When  new  systems  are  required  to  run  in  a  mode  that  emulates  outdated  equipment, 
increased  performance  benefits  of  the  newer  system  are  sacrificed.  These  benefits 
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that  are  sacrificed  are  often  the  justifications  for  procuring  the  system  in  the  first 
place.  [Ref.  39:p  48] 

A  current  example  of  this  liability  involves  the  Single  Channel 

Ground  Air  Radio  System  (SINCGARS).    SINCGARS  is  a  single  channel,  frequency 

hopping  VHF  radio  designed  to  be  resistant  to  jamming.    However,  in  order  to  operate 

with  the  older  PRC-77  and  VRC-12  VHF  radios,  it  must  often  suspend  its  frequency 

hopping  capability  and  operate  on  a  single  frequency. 

(3)  Interoperability  Costs  More.  Interoperability  requires  increased 
coordination.  This  requires  more  man  hours  which  leads  to  higher  costs.  These  man 
hours  result  from  increased  effort  in  configuration  management  and  from  the  limitations 
placed  on  the  size,  weight,  and  power  of  the  equipment  to  be  built.  Another  cost  in 
achieving  interoperability  is  attaining  backward  compatibility.  Backward  Compatibility 
entails  enabling  the  system  to  be  interoperable  with  older,  fielded  systems. 
Interoperability  can  be  achieved  through  any  suitable  method,  and  need  not  be  restricted 
to  technological  changes.  These  older  systems  usually  utilize  outdated  technology,  behind 
that  being  fielded  in  the  new  system.  It  can  become  cost  prohibitive  to  design  the  system 
in  development  to  both  comply  with  older  operational  standards  and  interfaces  and 
achieve  "state  of  the  art"  capability  as  well.  This  tends  to  restrict  the  full  utilization  of 
"state  of  the  art"  technology.  [Ref.  71] 
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C.      INTEROPERABILITY  ASSESSMENT 

1.      Findings  of  the  Naval  Research  Advisory  Committee 

The  Naval  Research  Advisory  Committee  (NRAC)  published  a  report  shortly 
after  the  demise  of  MIFASS.  The  report  examined  the  intra/interoperability  capabilities 
of  the  Marine  Corps.  They  found  that  many  interoperability  deficiencies  existed, 
primarily  due  to  a  lack  of  strong,  central  coordination.  This  led  to  many  configuration 
management  problems  with  MTACCS  and  its  associated  subsystems.  The  tactical  data 
interfaces  were  inadequately  defined  or  satisfied.  As  stated  earlier,  this  led  to  problems 
with  basic  interoperability  between  MIFASS  and  the  message  switch  that  was  to  handle 
MIFASS '  message  traffic.  The  documentation  was  reactive  instead  of  directive  and  was 
not  internally  consistent.  Standards  were  not  enforced  uniformly  and  waivers  were  the 
rule  instead  of  the  exception.  fRef.  8,43] 

The  committee  also  stated  that  the  crucial  performance  standard  of  a  C2  system  was 
its  level  of  interoperability  [Ref.  43].  A  C2  system  that  can  not  intemperate,  commands 
and  controls  very  little  and  receives  little  outside  information.  The  committee  proposed 
recommendations  for  improvements  in  three  areas.  Those  recommendations  are  outlined 
here: 

a.      Systems  Engineering 

The  system  baseline  should  be  based  on  an  open  architecture  with 
standard  interfaces.  This  will  allow  developers  and  designers  to  "plug  in"  their  projects 
and  will  force  a  set  of  standards.     System  engineers  must  concentrate  on  what  is 
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achievable  in  the  near  term  and  incrementally  enhance  the  system,  aiming  for  maximum 
integration  of  tactical  data  systems,  automated  information  systems,  and  tactical 
communications  systems.  [Ref.  43:p  4] 

b.  Management 

A  strong,  centralized  intra/interoperability  configuration  management 
authority  should  be  established  with  unambiguous  responsibility  for  all  tactical  data  and 
communications  systems.  Baseline  documents  should  be  transformed  into  authoritative 
guides.  These  documents  should  be  regularly  reviewed  and  updated  to  incorporate  new 
technology  and  maintain  internal  consistency.  [Ref.  43:p  5] 

Management  continuity  is  a  problem  that  can  be  solved  through  career 
planning  and  development  for  Marine  Corps  officers.  This  coupled  with  long  term 
technical  support  for  program  managers  should  enhance  configuration  management  and 
minimize  the  changes  to  requirements.  [Ref.  43 :p  5] 

c.  Implementing  Strategy 

The  Committee  stated  that  near  term  efforts  should  concentrate  on 
documentation  updates,  implementing  FIREMAN35,  and  planning  for  enhanced  tactical 
communications.  The  implementation  of  FIREMAN  should  be  treated  as  part  of  a  larger 
C2  systems,  and  not  just  a  separate  entity.  It  should  be  acquired  through  an  evolutionary 
strategy  using  off-the-shelf  equipment  and  software.  Command  and  control  data 
requirements  should  be  re-evaluated  for  all  phases  of  MAGTF  operations.    All  critical 


FIREMAN  has  developed  into  the  Tactical  Combat  Operations  (TCO)  system. 
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design  constraints  (such  as  data  security/integrity  and  system  robustness)  must  be  defined. 
An  overall  architecture  should  be  adopted  which  satisfies  near  term  needs  and  supports 
future  growth.    [Ref.  43  :p  5] 

2.      Current  Marine  Corps  Efforts  to  Enhance  Interoperability 

The  timely,  accurate,  efficient,  and  secure  flow  of  vital  processed  and  tailored 
information  is  the  key  to  removing  the  uncertainty  associated  with  the  chaos  of  war. 
[Ref.  73:p  81]  ...  technology  alone  is  not  the  total  solution.  It  is  absolutely 
essential  that  standards  be  developed  and  adhered  to  by  all  members  of  the  joint 
and  combined  community,  so  that  our  technologically  advanced  equipment  can 
interoperate  effectively  to  collect,  process,  and  disseminate  the  flood  of  information 
that  currently  threatens  to  inundate  the  commander.  [Ref.  73 :p  83] 

The  current  efforts  of  the  Marine  Corps  to  enhance  interoperability  are 

threefold. 

a.      Organizational  efforts 

In  an  effort  to  highlight  interoperability  requirements,  General  Alfred  M. 

Gray  has  reorganized  the  offices  responsible  for  interoperability  in  the  Marine  Corps.  In 

Signal  magazine,  General  Gray  wrote: 

The  Headquarters,  U.S.  Marine  Corps,  has  been  reorganized  to  merge  the 
Intelligence  and  Command,  Control,  Communications,  and  Computers  (C)  divisions 
into  the  Command,  Control,  Communications,  Computers,  Intelligence,  and 
Interoperability  (C*l2)  Department.  This  step  has,  for  the  first  time,  given  formal 
cross-discipline  visibility  in  the  complementary  fields  of  C4  and  intelligence.  With 
the  addition  of  the  second  "I"  for  interoperability,  that  concern  so  critical  to  C2 
systems  has  been  elevated  to  the  position  of  importance  that  it  deserves. 
[Ref.  73:p  82] 

This  reorganization  has  consolidated  the  interoperability  focus  to  facilitate 

the  coordination  and  distribution  of  standards,  yet  has  maintained  the  focus  in  three  key 
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areas  of  systems  development  and  acquisition.    Currently,  there  are  three  organizations 
responsible  for  ensuring  intra/interoperability: 


1.  C4I2  Section  at  HQMC  -  Responsible  for  establishing  policies  and  procedures  for 
assuring  intra/interoperability  of  all  Marine  Corps  systems. 

2.  MCCDC  -  Responsible  for  defining,  validating,  and  publishing 
intra/interoperability  requirements. 

3.  MCRDAC  -  Responsible  for  cataloging,  developing,  and  describing  approved 
Marine  Corps  intra/interoperability  standards  for  messages,  data  elements,  and 
communications  protocols.  [Ref.  74] 


The  relationships  between  these  sections  are  depicted  in  Figure  37.  The 
reorganization  should  aid  in  the  establishment  of  a  central  configuration  manager 
(MCRDAC),  with  clearly  defined  responsibilities  as  suggested  by  the  Naval  Research 
Advisory  Committee. 

There  are  two  interoperability  organizations  that  are  used  to  aid  in 
establishing  policy,  requirements,  and  standards.  The  first  is  the  Interoperability  Planning 
Board  (IPB),  chaired  by  the  Commanding  General,  Cl2  HQMC.  This  board  develops 
recommendations  for  interoperability  policy;  soliciting  responses  from  the  other 
organizations  as  shown  in  Figure  37.  This  board  also  controls  the  issuance  of  temporary 
waivers,  weighing  the  impact  of  the  waivers  on  other  Marine  Corps  systems.  The  second 
key  organization  is  the  Interoperability  Configuration  Control  Board  (ICCB).  This  board 
is  chaired  by  the  Commanding  General,  MCRDAC  and  makes  recommendations  to 
MCCDC  for  changes  to  interoperability  requirements  and  to  MCRDAC  for  changes  to 
interoperability  standards.    These  recommendations  are  based  on  input  from  the  Fleet 
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Figure  37:  Intra/Interoperability  Relationships  [Source:  Ref.  74] 
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Marine  Force  and  the  other  interoperability  organizations  depicted  in  Figure  37.  Through 
the  use  of  these  boards,  the  interoperability  cross  coordination  problem  between  programs 
that  plagued  MIFASS  should  be  avoided  in  MTACCS.  [Ref.  74] 

b.      Administrative  efforts 

There  are  a  number  of  documents  that  delineate  interoperability  guidance: 


1 .  MCO  3093.1.  This  order  establishes  policies  and  management  procedures  within 
the  Marine  Corps  to  ensure  that  both  Marine  Corps  intraoperability  and 
joint/combined  interoperability  standards  are  implemented  in  Marine  Corps  tactical 
C4I2  systems.  This  order  is  published  by  the  Assistant  Chief  of  Staff  for 
Command,  Control,  Communications,  Computers,  Intelligence,  and 
Interoperability.  [Ref.  74:p  1-3] 

2.  Interoperability  Management  Plan  (IMP).  This  plan  is  written  to  ensure  the 
exchange  of  critical  tactical  information  in  Marine  Corps  combat  operations 
through  interoperability  management.  Its  aim  is  to  facilitate  the  implementation, 
verification,  and  testing  of  standards  on  developing  tactical  data  systems, 
prescribing  coordination  between  various  configuration  management  bodies,  and 
to  ensure  interoperability  requirements  are  adequately  planned  for  and  properly 
funded.  The  plan  is  published  by  the  Assistant  Chief  of  Staff  for  Command, 
Control,  Communications,  Computers,  Intelligence,  and  Interoperability. 
[Ref.  75:p  1-3] 

3.  Marine  Corps  Interoperability  Configuration  Management  Plan  (MCICMP).  This 
plan  addresses  current  requirements  for  configuration  management  and 
interoperability  requirements  and  for  message,  data,  and  protocol  standards.  This 
plan  is  published  by  the  Assistant  Chief  of  Staff  for  Command,  Control, 
Communications,  Computers,  Intelligence,  and  Interoperability.  [Ref.  75:p  1-5] 

4.  MAGTF  Interoperability  Requirements  Concept  (MIRC).  The  purpose  of  this 
document  is  to  assist  in  meeting  interoperability  objectives  by  identifying  and 
documenting  interoperability  requirements  that  have  been  established  in  doctrine. 
Additionally,  this  document  is  to  provide  an  interoperability  requirements  baseline 
for  the  development  of  standards  contained  in  the  Technical  Interface  Design  Plan 
(TIDP),  and  to  validate  input  into  joint  C3  architectures.  This  plan  is  published 
by  the  Commanding  General,  Marine  Corps  Combat  Development  Command. 
[Ref.  76:p  1-3] 
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5.  Technical  Interface  Design  Plan  (TIDP).  This  document  provides  approved 
Marine  Corps  intraoperability  standards  including  message,  data  element,  and 
protocol  standards.  The  TIDP  provides  information  on  each  tactical  data  system's 
or  interconnecting  equipment's  interface  description  by  outlining  approved 
message,  data,  and  protocol  specifications  including  those  that  temporarily  deviate 
from  the  standard  through  approved  waivers.  This  document  is  published  by  the 
Commanding  General,  Marine  Corps  Research,  Development,  and  Acquisition 
Command.  [Ref.  77:p  1-3] 

6.  Interoperability  Data  Base  System  (IDBS).  The  IDBS  maintains  MIRC 
interoperability  requirements  and  supports  the  interoperability  program  and 
configuration  management  of  interoperability  requirements  and  standards. 
[Ref.  74] 


The  steps  to  interoperability  specifically  state  that  a  Technical  Interface 
Concept  Document  and  a  Technical  Interface  Design  Plan  be  written  to  aid 
interoperability.  As  noted  above,  the  Marine  Corps  complies  with  these 
recommendations.  The  steps  also  list  a  configuration  management  plan.  The  Marine 
Corps  has  written  an  Interoperability  Management  Plan  and  an  Interoperability 
Configuration  Management  Plan.  The  updating  and  rewriting  of  Marine  Corps 
Interoperability  documents  is  a  step  toward  fulfilling  Naval  Research  Advisory  Committee 
recommendations  to  redo  the  documentation.  NRAC  stated  that  the  documents  in  1987 
were  reactive  and  not  directive.  An  evaluation  of  the  rewritten  documents  was  not  an 
objective  of  this  thesis.  However,  the  increased  visibility  of  these  documents 
demonstrates  a  general  trend  towards  increased  interoperability  awareness. 

c.      Technical  efforts 

From  a  technical  aspect,  the  Marine  Corps  is  working  towards  increasing 
use  of  industry  standards.  This  will  allow  common,  tested  interfaces,  operating  systems, 
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and  hardware.  In  closely  watching  the  development  of  other  service  C3  systems,  the 
Marine  Corps  is  kept  abreast  of  what  it  will  take  to  maintain  interoperability. 
[Ref.  34:p  4.3] 

3.      Assessment  of  MTACCS  Efforts  to  Enhance  Interoperability 

a.  Introduction 

This  section  discusses  the  current  efforts,  for  which  documentation  was 
available,  in  MTACCS  and  how  they  measure  up  to  recommendations  that  have  been 
stated  concerning  the  proper  way  to  ensure  interoperability. 

b.  MTACCS  Interoperability  Elements 

(J )  Technical  Interface  Standards.  As  stated  in  a  report  commissioned 
of  the  Pacific  Northwest  Laboratories,  MTACCS  will  employ  industry  standards  for 
communications  and  storage  interfaces  and  will  use  NDI  common  buses  for  peripheral 
compatibility  [Ref.  34:p  4.3].  Repeatedly  stated  throughout  MTACCS  documentation,  is 
the  concept  of  common  hardware  and  common  software  [Ref.  2:p  1-5].  The  common 
hardware  and  software  must  meet  the  standard  interfaces  set  forth  in  the  Technical 
Interface  Design  Plan  (TIDP),  or  in  order  to  maintain  consistency,  the  standards  must 
change  to  keep  pace  with  technology.  This  will  save  in  redesigning  new  standards  and 
provide  industry  an  opportunity  to  start  designing  and  building  using  standards  with  which 
they  are  familiar.  This  will  allow  the  employment  of  a  wider  array  of  Commercial -off - 
the-Shelf  items  and  will  greatly  enhance  interoperability  due  to  the  great  proliferation  of 
similar  computers  throughout  the  military  around  the  world.    The  system  is  to  be  built 
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around  an  open  architecture  using  a  modular  concept.  This  will  facilitate  the 
upgradability  of  the  system,  and  should  be  readily  attainable  through  the  use  of  predefined 
hardware  and  software  interfaces. 

(2)  Message  Standards.  Message  standards  have  been  published  in  the 
Technical  Interface  Design  Plan  (TIDP)  However,  Pacific  Northwest  Laboratories  has 
stated  that  these  are  incomplete  for  use  across  all  MTACCS  functional  areas  and  cautions 
against  progressing  past  FDS  1,  until  there  has  been  a  proper  integration  of  applicable 
Marine  Tactical  System  (MTS)  messages  [Ref.  34:p  4.33].  The  use  of  the  POSIX36  for 
system  support  software  does  allow  for  a  limited  variety  of  message  formats 
[Ref.  34:p  4.9].  The  program  managers  and  prime  contractors  of  MTACCS  subsystems 
were  interviewed  concerning  the  impact  MTACCS  would  have  on  their  system.  A  large 
part  of  the  discussion  centered  on  the  impact  of  connectivity,  namely  the  message  formats 
and  operating  systems.  The  visibility  of  this  problem  is  one  positive  step  in  the  correct 
direction.  [Ref.  34:p  4.1] 

(3)  Operating  Procedures.  At  this  point  in  time,  specific  operating 
procedures  have  not  been  defined.  As  stated  later  in  this  section,  MTACCS  is  currently 
in  step  two,  specification  of  interfaces  and  information,  of  the  steps  to  interoperability. 
This  step  must  be  completed  before  step  three,  specification  of  operating  procedures. 
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A  standardized  open  system  computer  operating  environment  based  on  UNIX. 


190 


(4)  Database  and  Program  Applications  Standards.  At  this  point  in 
time,  the  Marine  Corps  has  decided  there  would  be  common  software  and  common 
applications  programs.  This  lends  itself  to  interoperability,  at  least  within  the  Marine 
Corps,  by  the  use  of  the  same  systems.  The  Marine  Corps  is  currently  investigating 
Database  Management  Systems  (DBMS)  and  has  not  yet  set  a  standard.  [Ref.  34:p  4.20] 

c.      MTACCS  Level  of  Interoperability 

(1)  Current.  Currently,  the  Marine  Corps  has  made  great  strides  through 
Operation  Desert  Storm.  Many  communications  problems  have  been,  at  least  temporarily, 
ironed  out  through  the  use  of  borrowed  or  reconfigured  equipment.  The  aviation  element 
of  the  Marine  Corps  has  been  interoperable  for  many  years,  not  in  every  system,  but  in 
the  overall  scheme.  Useable  information  in  the  proper  format  is  passed  to  other  services 
and  foreign  militaries.  In  examining  the  levels  of  interoperability,  the  majority  of  the 
Marine  Corps  would  fall  in  the  "swivel  chair"  or  liaison  team  category  of  interoperability. 
A  Marine  would  physically  transfer  the  information  from  one  system  to  the  other,  be  it 
a  manual  or  automated  system,  or  explain  a  situation  and  transfer  information  to  another 
organization.  As  stated  above,  much  of  the  aviation  element  of  the  Marine  Corps 
interoperates  in  the  common  mode.  Different  systems  with  common  methods  of 
transferring  data. 

(2)  Anticipated.  The  intent  in  integrating  MTACCS  with  fully 
developed  and/or  fielded  systems  is  to  only  integrate  them  to  the  extent  possible  without 
causing  major  revisions  to  their  elements  [Ref.  32:p  17].  This  infers  that  major  systems 
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that  are  to  be  fielded  will  only  make  minor  changes,  initially  to  enhance  interoperability. 
Long  term  interoperability  standards  will  be  developed,  but  compliance  with  those 
standards  will  be  achieved  in  an  evolutionary  manner.  There  will  be  limited  forced 
interoperability  at  first,  and  then  through  the  evolutionary  development  of  MTACCS  and 
the  product  improvements  of  its  subsystems,  MTACCS  will  achieve  a  greater  measure  of 
interoperability  in  time.  It  is  envisioned  that  a  "swivel  chair"  interoperability  will  be 
attained  with  systems  currently  developed.  Systems  in  development  should  be  able  to 
attain  some  common  modes  of  operation.  Gateways  will  be  developed  to  increase 
interoperability  until  systems  life  cycles  progress  in  that  their  interoperability  is  upgraded 
through  product  improvement.  Through  these  product  improvements,  MTACCS  will 
achieve,  in  an  evolutionary  manner,  full  integrated  interoperability.  Interoperability  with 
other  services  would  be  achieved  through  common  modes  of  operation  and  gateways. 
Pacific  Northwest  Laboratories  has  been  examining  the  functioning  of  the  Army  ATCCS 
and  CASS  programs  as  a  reference  for  MTACCS.  [Ref.  34:p  ii] 

d.      MTACCS  Steps  to  Interoperability 

Currently  the  MTACCS  program  appears  to  be  in  the  second  step  of 
specifying  the  technical  interfaces  and  the  information  to  be  exchanged  [Ref.  34].  The 
first  step  was  accomplished  in  the  original  MTACCS  concept  stated  in  the  late  1960's  and 
redone  in  the  revitalization  of  the  late  1980's. 
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e.      Avoidance  of  Historical  Problem  Areas 

(J)  Management.  As  stated  in  MCO  3093.1  C,  only  one  agency  has  the 
responsibility  for  setting  and  maintaining  standards,  MCRDAC.  The  others,  C4I2  and 
MCCDC,  identify  problems,  requirements,  and  set  policy.  The  directives  more  clearly 
delineate  standards  and  responsibility,  although  they  apparently  could  be  better,  they  are 
a  step  in  the  correct  direction  [Ref.  34].  At  MCRDAC,  an  office  responsible  for 
disciplining  the  development  of  systems  in  accordance  with  set  standards  was  established 
to  ensure  configuration  management  [Ref.  34:p  A.33].  The  last  historical  problem  is  that 
of  proper  priority.  Interoperability  has  been  a  key  buzzword  for  many  years  and  is 
enjoying  a  lot  of  popularity.  It  is  difficult  to  assess  if  this  is  enough  to  make  an  impact. 

(2)  Architectural.  MTACCS  is  defined  as  having  an  open  architecture. 
It  is  being  built  in  software  modules  on  common  operating  systems.  Common  types  of 
hardware  are  being  used  on  which  to  operate  the  system.  [Ref.  34]  This  should  ease 
configuration  changes  and  upgrades  to  the  system.  This  should  also  enhance 
interoperability  through  the  use  of  modules. 

(3)  Standards.  A  key  guideline  for  MTACCS  has  been  to  establish 
standards  early.  An  early  definition  of  standards  can  prevent  a  profusion  of  incompatible 
"standards.  Early  MTACCS  subsystems,  such  as  MIFASS,  developed  unique  interfaces 
in  the  absence  of  an  enforced  common  standard.  The  result  was  the  incompatibility  of 
MIFASS  with  other  MTACCS  systems.  Pacific  Northwest  Laboratories  has  reinforced 
the  concept  of  early  standard  development  throughout  their  study.  [Ref.  34]    As  stated 
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before,  the  Marine  Corps  has  rewritten  a  number  of  its  intra/interoperability  standards 
documents  and  continues  to  examine  solutions  for  undefined  standards. 

(4)  Systems.  Backward  compatibility  could  be  an  extensive  problem. 
Pacific  Northwest  Laboratories  has  examined  the  problems  of  interfacing  with  established 
systems  [Ref.  34].  While  backward  compatibility  can  be  achieved  by  an  interoperability 
method,  a  technological  solutions  appear  to  be  the  method  of  choice.  Technological 
problems  are  beyond  the  scope  of  this  thesis.  However,  a  high  priority  must  be  given  to 
backward  compatibility,  or  the  older,  incompatible  systems  must  be  eliminated. 

D.      CONCLUSIONS 

History  is  filled  with  examples  of  vastly  superior  forces  failing  to  prevail  or 
suffering  actual  defeat  at  the  hands  of  dramatically  weaker  forces  that  possessed 
more  flexible,  responsive  and  effective  C2  ...  our  intention  is  to  ensure  that  our  C2 
systems  foster  sound  tactical  decisions  that  will  enable  commanders  to  focus  their 
tremendous  combat  power  at  the  enemy's  center  of  gravity.  [Ref.  73:p  83] 

MTACCS  should  not  significantly  change  operationally,  the  way  Marines  fight.  It 

will  provide  more  processed  and  useable  information  to  the  commander  and  reduce  his 

processing  time.     Neither  tactics,  strategy,  nor  procedures  are  scheduled  to  change. 

[Ref.  27]  Interoperability  will  be  achieved  by  establishing  standards  and  complying  with 

these  standards  in  an  evolutionary  manner.  As  MTACCS  evolves,  the  various  subsystem 

will  progress  through  several  levels  or  methods  of  interoperability.    A  subsystem  may 

utilize  liaison  teams  at  first,  then  progress  to  a  common  mode  or  gateway,  and  eventually 

achieve  full  integration.   It  is  envisioned  that  as  the  system  is  used,  more  efficient  and 

effective  methods  of  operation  will  be  discovered.  As  each  service  gains  experience  and 
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shares  the  knowledge  gained,  higher  levels  of  interoperability  will  be  achieved.  As 
demonstrated  in  Operation  Desert  Storm,  the  U.S.  Military  will  be  fighting  in  a  arena  with 
not  just  the  other  services,  or  NATO  allies,  but  with  a  significant  portion  of  the  world. 
A  computer  terminal  with  translation,  electronic  mapping,  and  message  handling 
capability  can  gready  enhance  the  power  focused  at  the  enemy's  critical  mass  and  is 
much  more  efficient  than  a  liaison  team.  While  more  efficient,  automated  systems  are 
not  necessarily  more  effective.  In  actuality,  liaison  teams  can  not  be  completely  replaced 
by  automated  systems.  Liaison  teams  provide  a  richness  of  information  not  found  in 
automated  systems. 
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vm.  CONCLUSIONS 

A.      SUMMARY 

1.  Purpose  of  the  Assessment 

The  driving  goal  of  this  assessment  is  to  develop  an  understanding  of  the 
strengths  and  the  possible  risks  inherent  in  the  new  MTACCS  concept.  Additionally, 
recommendations  are  proposed  that  offer  methods  of  mitigating  the  impact  of  identified 
risk  factors. 

2.  A  Challenging  Task 

A  quarter  of  a  century  has  passed  since  the  inception  of  MTACCS.  Tens  of 
thousands  of  man  years  have  been  invested  in  its  development.  Assessment  of  a  project 
of  this  scope  is  an  enormous  challenge.  The  authors  have  expended  considerable  effort 
simply  in  attempting  to  develop  a  thorough  understanding  of  the  many  complex  issues 
involved. 

3.  Limitations  of  the  Assessment 

The  scope  of  this  assessment  is  very  broad.  Emphasis  on  any  one  subject  has 
been  necessarily  limited.  Many  of  the  guiding  directives  and  planning  documents  are 
written  only  in  draft  or  are  not  yet  written  at  all.  Additionally,  the  MTACCS  program 
is  dynamic  and  evolving.  Some  concept  decisions  are  being  made  even  as  this  assessment 
is  being  written.     All  of  these  factors  place  limitations  on  the  credibility  of  the 
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assessment.  Much  of  the  information  contained  in  the  assessment,  however,  remains 
current.  The  conclusions  are  intended  to  be  general  and  do  not  address  a  fine  level  of 
detail.  A  finer  level  of  detail  is  beyond  the  scope  of  this  effort  due  to  the  limitations  that 
have  been  discussed. 

4.      Methodology 

An  assessment  of  a  command  and  control  system  may  examine  many  factors. 
Assessments  typically  examine  program  management  procedures,  cost-effectiveness, 
performance,  etc.  In  the  case  of  MTACCS,  the  failure  of  the  key  MTACCS  subsystem, 
known  as  the  Marine  Integrated  Fire  and  Air  Support  System  (MIFASS),  was  viewed  as 
a  principle  driver  of  the  "revitalized"  concept.  A  thorough  investigation  of  the  MIFASS 
program  revealed  several  key  ares  of  concern.  Important  among  these  were  the  basic 
feasibility  of  the  project,  cost-effectiveness,  combat  development  practices,  and 
interoperability.  This  assessment  then  attempts  to  determine  the  likelihood  of  the 
"revitalized"  MTACCS  experiencing  problems  in  the  same  areas. 

This  assessment  began  with  an  investigation  of  a  key  MTACCS  subsystem. 
MIFASS  had  crippling  acquisition  and  system  engineering  problems  and  the  project  was 
canceled  in  1987  after  almost  twenty  years  in  development  Chapter  II  detailed  the 
difficulties  encountered  during  the  MIFASS  program  and  discussed  the  causes  of  the 
MIFASS  failure. 

After  the  termination  of  MIFASS,  the  MTACCS  program  was  re-evaluated  and 
a  "revitalized"  concept  was  published.  Chapter  in  described  the  MTACCS  concept  as  it 
is  currently  envisioned.    Many  of  the  guiding  directives  and  strategy  documents  that 
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define  MTACCS,  however,  are  still  in  draft.  While  the  basic  thrust  of  the  new  concept 
is  stable,  some  changes  in  concept  definition  are  occurring  even  as  this  thesis  is  being 
written. 

The  implementation  of  MTACCS  is  an  extreme  challenge.  At  least  several  of 
the  objectives  of  MTACCS  fall  into  the  "high  risk"  category  and  may  not  even  be 
possible  to  achieve  at  any  reasonable  cost  and  expenditure  of  effort.  The  assessment  in 
Chapter  IV  was  an  evaluation  of  the  feasibility  of  the  MTACCS  goals. 

It  is  often  tacitly  accepted  that  the  automation  of  a  particular  task  has  inherent 
benefits  that  always  result  in  improved  combat  effectiveness.  Chapter  V  addressed  the 
potential  cost-effectiveness  of  MTACCS.  The  cost  of  MTACCS  was  related  to  its  ability 
to  increase  effectiveness  to  determine  if  spending  funds  on  MTACCS  is  an  optimal  use 
of  resources. 

In  Chapter  VI,  the  Marine  Corps'  Combat  Development  practices  were 
reviewed  to  determine  the  impact  of  combat  development  on  MTACCS. 

Chapter  VII  provided  an  assessment  of  the  interoperability  efforts  of  MTACCS 
and  the  levels  of  interoperability  expected  to  be  achieved. 
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B.       CONCLUSIONS 
1.      MIFASS 

a.  Key  Problems 

There  were  four  key  problems  within  the  MIFASS  program: 

1.  A   lack  of  consensus  concerning  the  doctrinal   issue  of  centralization   versus 
decentralization. 

2.  Unstable  requirements  definition  that  failed  to  state  requirements  in  mission  terms. 

3.  Underestimation  of  the  complexity  of  the  task. 

4.  Adherence  to  the  traditional  approach  of  concentration  on  hardware  first  and  then 
the  software. 

The  clumsy  and  inefficient  management  system  was  a  hindrance  to  the 
program,  but  the  only  devastating  problem  was  the  lack  of  the  foundation  necessary  to 
establish  the  program  in  the  first  place:  sound  initial  requirements  definition  based  on 
appropriate  doctrine. 

b.  The  Impact  of  MIFASS  on  MTACCS 

In  response  to  both  the  Gold  water-Nichols  Reorganization  Act  of  1986, 
and  the  termination  of  MIFASS  in  1987,  the  procurement  business  in  the  Marine  Corps 
has  been  radically  changed.  The  old  matrix  organization  has  been  replaced  with  a 
dramatically  different  acquisition  system. 

It  is  unlikely  that  future  Marine  Corps  efforts  will  try  the  "big  system 
approach"  with  simultaneous  development  of  several  elements  of  the  Marine  Corps  in  one 
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big  step37.  Wary  of  falling  into  that  trap  again,  current  Marine  Corps  philosophy 
embraces  the  ideas  of  modular,  evolutionary  acquisition  using  non-developmental  items 
as  much  as  possible.  The  "build  a  little,  test  a  little,  field  a  little"  approach  will  be  used 
to  prevent  another  MIFASS  from  happening.  Avoiding  the  "big  system  approach", 
however,  may  result  in  a  reliance  on  simple,  basic  solutions  that  trade  away  efficiency 
and  effectiveness  for  simplicity. 

Only  one  aspect  of  the  "big  system  approach"  need  be  avoided.  The 
Marine  Corps  should  not  attempt  to  develop  a  major  system  such  as  MTACCS  in  one  big 
step.  An  evolutionary  development  is  the  preferred  method.  The  second  aspect  of  the 
"big  system  approach",  however,  remains  a  legitimate  requirement.  Integrated  solutions 
that  address  all  elements  of  the  Marine  Corps  system  are  necessary  to  maximize  combat 
effectiveness  within  resource  constraints. 

2.      The  New  MTACCS  Concept 

a.      General 

The  new  MTACCS  concept  properly  anticipates  the  need  for  an 
automated  command  and  control  system  to  support  MAGTF  operations.  Automation  of 
command  and  control  tasks  has  the  potential  of  significantly  increasing  the  combat 
effectiveness  of  Marine  forces. 


The  "big  system  approach"basically  entails  simultaneous  development  of 
elements  such  as  doctrine,  force  structures,  and  equipment  and  an  emphasis  on  achieving 
an  acceptable  system  in  one  iteration. 
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b.      Feasibility 

The  MTACCS  concept  is  feasible.  The  use  of  an  Evolutionary 
Acquisition  strategy  markedly  strengthens  the  program.  In  an  evolutionary,  incremental 
development,  advances  in  technology  can  be  more  readily  introduced  as  upgrades  to  the 
core  system.  There  are  several  factors,  however,  that  can  undermine  the  basic  feasibility 
of  the  project.  These  factors  must  be  addressed  and  mitigated  to  ensure  they  do  not 
inhibit  development. 

(1 )  Use  of  Data  Communications.  The  MTACCS  program  must  ensure 
that  informal  communications  and  voice  radio  are  not  entirely  supplanted  by  data 
communications.  To  rely  too  heavily  on  data  transmissions  violates  the  spirit  of  Marine 
Corps  doctrine  and  runs  the  risk,  as  Van  Creveld  said,  of  "reducing  command  to  trivia" 
[Ref.  41  :p  273]. 

(2)  Centralization.  A  clear  vision  of  the  degree  of  centralization  of 
command  and  control  must  be  established  early  and  maintained.  In  addition,  it  is  vital 
that  the  degree  of  centralization  be  strongly  supported  across  the  entire  Marine  Corps. 
There  must  be  consensus.  Division  on  this  highly  critical  issue  can  cripple  the  program. 

(3)  Communications  Capacity.  The  simultaneous  development  of  both 
MTACCS  and  its  supporting  communications  system  is  a  hauntingly  familiar  scenario. 
The  MIFASS  system  was  also  intended  to  operate  with  communications  equipment  that 
was  being  developed  concurrently.  The  communications  capacity  was  inadequate  then 
and  it  appears  that  the  capacity  remains  inadequate  despite  the  fielding  of  new  equipment. 
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(4)  Multi-level  Security.  There  is  a  need  to  allow  users  of  differing 
security  levels  to  be  able  to  access  the  same  system  using  the  same  database.  Until  this 
can  be  done  with  a  high  degree  of  confidence,  our  intelligence  sources  could  quite 
possibly  be  in  jeopardy.  Our  intelligence  system  could  be  unintentionally  violated. 
Fortunately,  there  appears  to  be  a  strong  interest  displayed,  by  both  industry  and  the 
services,  in  the  development  of  multi-level  security  for  both  military  and  commercial 
applications.  It  appears  that  the  Marine  Corps  need  only  follow  those  developments 
closely  and  evaluate  candidate  methods  to  determine  the  method  most  appropriate  for 
Marine  Corps  needs. 

(5)  Software  development.  The  MTACCS  development  team  has  laid 
out  a  development  plan  that  incorporates  all  of  the  current  "best  advice".  Adherence  to 
this  advice  will  certainly  promote  success.  The  challenge  remains  significant,  however. 
Furthermore,  the  decision  to  maintain  current  doctrine  and  force  structure  without 
modification  eliminates  potential  sources  of  mitigation  of  software  complexity.  It  is 
possible,  for  example,  that  changes  to  doctrine  could  reduce  the  software  burden. 

c.      Cost-Effectiveness 

Automation  of  command  and  control  functions  has  the  potential  to 
significantly  enhance  the  combat  effectiveness  of  the  Marine  Corps.  The  proper  level  of 
automation,  however,  may  not  be  "all  you  can  get".  The  most  cost  effective  level  of 
automation  may  be  that  which  restricts  automation  to  the  higher  headquarters;  regiments 
and  above.  The  value  of  automation  at  the  lower  echelons  (battalion  and  below)  can  be 
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relatively  small.  Generally,  this  is  because  the  burden  of  additional  equipment  and 
training  requirements  can  outweigh  the  increased  performance  gained  through  automation. 
Additionally,  many  C2  tasks  at  lower  levels  do  not  lend  themselves  to  automation. 
[Ref.  58:p  11] 

Based  on  the  results  of  the  TCO  study,  automation  of  command  and 
control  tasks  at  the  battalion  level  and  below  may  not  be  the  most  cost-effective  method 
of  increasing  combat  effectiveness.  The  implication  of  this  study  is  clear.  Cost-effective 
automation  of  C2  tasks  at  battalion  level  and  below  requires  lightweight,  easy  to  use 
equipment  that  addresses  only  those  tasks  that  require  automation. 

d.      Combat  Development 

(J)  Trends  in  the  Development  of  Command  and  Control  Systems. 
Currently,  there  appears  to  be  four  general  trends  in  the  development  of  C2  systems.  The 
first  is  an  emphasis  on  equipment  or  materiel  solutions.  MTACCS  appears  to  follow  this 
trend.  The  MTACCS  Master  Acquisition  Plan  states  that  current  command  and  control 
tasks  will  be  automated  (new  equipment)  but  no  changes  will  be  made  to  force  structure, 
doctrine,  etc. 

The  second  trend  is  a  reliance  on  basic  solutions  that  addresses  only 
one  element  of  a  complex  system.  MTACCS,  for  example,  addresses  primarily  materiel. 
Other  elements  of  the  Marine  Corps  "system"  will  not  be  modified. 
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The  tlii fcl  trend  Is  the  use  of  an  "applique  approach"  for  command 
and  control  Systems.  Force  Structure,  doctrine,  and  procedures  are  defined  first  and  the 
("'  system  is  applied  as  an  applique.    Mere,  too,  MTACCS  appears  to  follow  the  trend. 

The  last  trend  is  the  increasing  emphasis  of  standardization  over 
Optimization.  Merely  coping  with  technology  is  consuming  a  majority  of  our  efforts. 
Optimizing  appears  to  he  a  lesser  concern.  MTACCS  may  well  he  following  this  trend 
as  well.    Only  small,  incremental  improvements  to  automation  are  expected.    Gradually, 

these  incremental  improvements  will  achieve  a  desired  level  of  automation.  The  majority 

Of  emphasis,  however,  appears  tO  be  in  achieving  a  working  system  rather  than  optimizing 

effectiveness. 

(2 )    Little  Faith  in  the  "Big  System  Approach".  As  mentioned  previously, 

the  failure  of  Mil  ASS  has  caused  the  Marine  Corps  to  have  little  faith  in  the  "big  system 
approach."  This  is  unfortunate  because  it  appears  that  the  chosen  alternative  is  a  tendency 
to  develop  only  one  element  of  the  system  at  a  time:  change  some  equipment,  for 
example,  and  keep  all  other  system  elements  relatively  static.  While  this  method  is  less 
complex,  it  trades  a  great  deal  o\'  effectiveness  away  to  achieve  that  lower  level  of 
complexity.  Regardless  of  the  had  experience  ol  MIl'ASS,  there  remains  a  need  to 
implement  change  in  a  manner  that  integrates  all  oi  the  elements  of  the  system. 

The  reduction  Of  complexity  through  the  use  of  an  evolutionary 
development  scheme  is  highly  desirable.  Attempting  to  further  reduce  complexity  by 
addressing  only  equipment,  for  example,  may  be  sacrificing  too  much  effectiveness  for 
the  sake  o\  simplicity.     Standardization  is  emphasized  more  than  optimization.     The 
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integrated  development  of  all  elements  of  the  Marine  Corps  "system"  in  an  evolutionary 
manner  has  the  potential  of  promoting  both  optimization  and  standardization. 

(3)  The  Need  for  Systems  Engineering  in  the  Marine  Corps.  In  recent 
years,  revolutionary  advances  have  occurred  most  often  in  the  development  of  weapons 
and  equipment.  Users  and  developers  alike  are  tempted  to  solve  most  deficiencies  with 
new  technology.  The  MTACCS  program  is  following  a  similar  approach.  Basically,  only 
equipment  will  be  changed.   Force  structure  and  doctrine  will  remain  unaltered. 

New  technology  alone,  however,  focuses  on  only  one  element  of  a 
complex  system.  While  technology  is  capable  of  marvelous  achievements,  it  continues 
to  be  only  a  part  of  a  larger  system.  Equal  attention  must  be  given  to  all  elements  of  the 
system  to  ensure  optimal  use  of  resources.  Modifications  to  doctrine,  procedures,  or  force 
structure,  for  example,  may  better  complement  a  major  advance  in  C2  technology  than  the 
current  doctrine  or  procedures. 

Adherence  to  a  systems  engineering  process  in  combat  development 
has  the  potential  of  mitigating  the  current  trends  and  restoring  the  oft  neglected  elements 
of  the  system  to  their  proper  levels  of  emphasis.  Through  trade-off  studies,  for  example, 
appropriate  doctrine,  level  of  personnel,  and  types  of  equipment  can  be  carefully  chosen 
to  optimize  effectiveness  within  resource  constraints. 

e.      Interoperability 

It  is  important  to  note  that  100%  automated  interoperability  is  neither 
necessary  nor  desired.  Some  method  of  interoperability  must  be  utilized  but  that  need  not 
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entail  an  automated  capability.  In  the  case  of  MTACCS,  interoperability  will  be  achieved 
by  establishing  standards  and  complying  with  those  standards  in  an  evolutionary  manner. 
It  is  envisioned  that  as  the  system  is  used,  more  efficient  and  effective  methods  of 
operation  will  be  discovered.  As  MTACCS  evolves,  the  various  subsystems  will  progress 
through  several  levels  or  methods  of  interoperability.  A  system  may  utilize  liaison  teams 
at  first,  then  progress  to  a  common  mode  or  gateway,  for  example.  Automated 
interoperability  of  all  C2  systems  in  the  long  term  is  a  principle  goal  of  the  MTACCS 
concept.  Computer  terminals  with  translation,  electronic  mapping,  and  message  handling 
capability  can  greatly  enhance  the  power  focused  at  the  enemy's  critical  mass  and  are 
more  efficient  than  liaison  teams,  for  example.  Liaison  teams,  however,  will  never  be 
entirely  supplanted  by  automated  methods.  Liaison  teams  provide  a  richness  of 
information  to  the  supported  unit  that  is  generally  impossible  to  achieve  through 
automation  alone. 

C.      RECOMMENDATIONS 

The  conclusions  that  have  been  expressed  in  this  chapter  indicate  that  the 
development  of  MTACCS  remains  a  significant  challenge.  Several  risk  factors  have  the 
potential  of  seriously  impeding  the  progress  of  MTACCS.  Mitigation  of  these  risk  factors 
is  not  an  easy  task.  The  following  recommendations  offer  potential  opportunities  for 
lessening  the  developmental  risk  inherent  in  the  MTACCS  programs  and  increasing 
combat  effectiveness. 
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Sufficient  voice  channels  must  be  maintained  in  the  MTACCS  system  to  support 
the  concept  of  "implicit  communications"  because  we  communicate  in  how  we 
talk;  in  our  inflection  and  our  tone  of  voice. 

The  developers  of  MTACCS  recognize  that  the  communications  capacity  of 
current  and  near  term  Marine  Corps  equipment  will  quite  probably  be  exceeded 
by  MTACCS.  A  determination  of  the  anticipated  communications  capacity  need 
is  difficult  without  a  firm  understanding  of  the  specific  information  exchange 
requirements  of  MTACCS  which  have  yet  to  be  developed.  Regardless,  the 
communications  capacity  requirement  for  MTACCS  must  be  determined  quickly 
to  allow  for  timely  development  of  a  solution  to  the  problem. 

Continued  emphasis  must  be  placed  on  establishing  multi-level  security  if  TCO 
is  to  interface  with  IAS  and  provide  unit  commanders  with  real  time  intelligence. 
Without  a  demonstrated  secure,  trusted  system,  there  will  be  little  user  support  for 
allowing  classified  information  of  a  sensitive  nature  to  be  passed  on  MTACCS 
nets. 

The  lack  of  faith  in  a  "big  system  approach"  should  not  be  permitted  to  cause  a 
complete  departure  from  integrated  solutions.  Some  effort  should  be  made  to 
permit  the  concurrent  evolution  of  doctrine,  force  structure,  and  procedures  as  well 
as  material.  Instituting  the  FASC  concept  along  with  current  MTACCS  objective, 
for  example,  may  offer  still  greater  effectiveness.  Evolutionary  development 
would  remain  the  method  of  choice.  The  solution  being  developed  would 
certainly  be  more  complex.  A  total  reliance  on  basic  solutions  should  be  avoided. 
Attempts  to  break  a  complex  problem  down  into  basic,  manageable  pieces  have, 
in  the  past,  resulted  in  many  of  the  pieces  being  solved  independently.  This  can 
lead  to  disjoint  solutions  that  do  not  maximize  combat  effectiveness  within  the 
imposed  resource  constraints. 
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APPENDIX  A:  GLOSSARY 


AAW 

ACAT 

ACE 

ACG 

ACMC 

ADM 

ADPE-FMF 

AE 

AEP 

AFATDS 

AIC 

AOA 

APO 

APS 

ARC 

ASP 

ASPO 

ATACC 

ATCCS 

ATDL-1 

ATO 

C2 

C3 

C3I 

Cl 

C4I2 

CATF 
CBRS 
CECOM 

err 

CLF 
CMC 


Antiair  Warfare 

Acquisition  Category 

Aviation  Combat  Element 

Acquisition  Coordinating  Group 

Assistant  Commandant  of  the  Marine  Corps 

Acquisition  Decision  Memorandum 

Automatic  Data  Processing  Equipment  -  Fleet  Marine  Force 

Acquisition  Executive 

Adaptability  Evaluation  Program 

Advanced  Field  Artillery  Tactical  Data  System 

Automated  Information  Center 

Amphibious  Operational  Area 

Acquisition  Project  Officer 

Acquisition  Program  Sponsor 

Atlantic  Research  Corporation 

Acquisition  Strategy  Plan 

Acquisition  Sponsor  Project  Officer 

Advanced  Tactical  Air  Command  Central 

Army  Tactical  Command  and  Control  System 

Army  Tactical  Data  Link-1 

Air  Tasking  Order 

Command  and  Control 

Command,  Control,  and  Communications 

Command,  Control,  Communications,  and  Intelligence 

Command,  Control,  Communications,  Computers,  and  Intelligence 

Command,  Control,  Communications,  Computers,  Intelligence,  and 

Interoperability 

Commander  Amphibious  Task  Force 

Concept  Based  Requirements  System 

U.S.  Army  Communications-Electronics  Command 

Counter  Intelligence  Team 

Commander  Landing  Force 

Commandant  of  the  Marine  Corps 
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CNA  Center  for  Naval  Analyses 

COC  Combat  Operations  Center 

Comm  Communications 

COTS  Commercial-Off-The-Shelf 

CSI  Command  Systems  Incorporated 

CSS  Combat  Service  Support 

CSSCS  Combat  Service  Support  Control  System 

DASC  Direct  Air  Support  Center 

DBMS  Database  Management  System 

DC  Development  Coordinator 

DCS  Defense  Communications  System 

DOS  Deputy  Chief  of  Staff 

DCT  Digital  Communications  Terminal 

DirDevCtr  Director  of  the  Development  Center 

DOD  Department  of  Defense 

DPM  Deputy  Program  Manager 

DPO  Development  Project  Officer 

ECM  Electronic  Counter  Measures 

EDM  Engineering  Development  Model 

EW  Electronic  Warfare 

FASC  Fire  and  Air  Support  Center 

FDC  Fire  Direction  Center 

FDS  Field  Development  System 

FIREFLEX  Marine  Corps  Flexible  Fire  Support  System 

FIREMAN  Marine  Corps  Fire  and  Maneuver  System 

FMF  Fleet  Marine  Force 

FSCC  Fire  Support  Coordination  Center 

GAO  General  Accounting  Office 

GCE  Ground  Combat  Element 

GOR  General  Operational  Requirement 

GPS  Global  Positioning  System 

HQMC  Headquarters  Marine  Corps 

HR  Helicopter  Request 

IAC  Intelligence  Analysis  Center 

IAS  Intelligence  Analysis  System 

IDA  Institute  for  Defense  Analysis 

IDASC  Improved  Direct  Air  Support  Center 

IFASC  Improved  Force  Automated  Services  Center 
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IDBS  Interoperability  Database  System 

IIF  Imagery  Interpretation  Facility 

ILSP  Integrated  Logistics  Support  Plan 

IMP  Interoperability  Management  Plan 

IOC  Initial  Operating  Capability 

IP  Imaging  Processor 

ISIS  Integrated  Signals  Intelligence  System 

ITT  Interrogation  Translation  Team 

JCS  Joint  Chiefs  of  Staff 

JSIPS  Joint  Service  Imagery  Processing  System 

JSP  Joint  Service  Program 

JTC3A  Joint  Tactical  C3  Agency 

LAAD  Low  Altitude  Area  Defense 

LAAM  Light  Antiaircraft  Missile  Battalion 

LCAC  Landing  Craft  Air  Cushion 

LCCF  Life  Cycle  Cost  Forecast 

LHD  Amphibious  Assault  Ship 

MACCS  Marine  Air  Command  and  Control  System 

MAFATDS  Multi-service  Advanced  Field  Artillery  Tactical  Data  System 

MAGIS  Marine  Air-Ground  Intelligence  System 

MAGTF  Marine  Air  Ground  Task  Force 

MAP  Master  Acquisition  Plan 

MATCALS  Marine  Air  Traffic  Control  and  Landing  System 

MCASS  MTACCS  Common  Application  Support  Software 

MCCDC  Marine  Corps  Combat  Development  Command 

MCEB  Military  Communications  Electronics  Board 

MCICMP  Marine  Corps  Interoperability  Configuration  Management  Plan 

MIRC  MAGTF  Interoperability  Requirements  Concept 

MCO  Marine  Corps  Order 

MCOTEA  Marine  Corps  Operational  Test  and  Evaluation  Activity 

MCDEC  Marine  Corps  Development  and  Education  Command 

MCRDAC  Marine  Corps  Research,  Development,  and  Acquisition  Command 

MCTSSA  Marine  Corps  Tactical  Systems  Support  Activity 

MEB  Marine  Expeditionary  Brigade 

MEF  Marine  Expeditionary  Force 

MEU  Marine  Expeditionary  Unit 

MIFASS  Marine  Integrated  Fire  and  Air  Support  System 

MILOGS  Marine  Integrated  Logistics  System 
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MIPLOG  Marine  Integrated  Personnel  and  Logistics 

MIPS  Marine  Integrated  Personnel  System 

MOE  Measure  of  Effectiveness 

MOFE  Measure  of  Force  Effectiveness 

MOP  Measure  of  Performance 

MTACCS  Marine  Tactical  Command  and  Control  System 

MTP  Manpower  Training  Plan 

MTS  Marine  Tactical  System 

NAVELEX  Naval  Electronic  Systems  Command 

NRAC  Naval  Research  Advisory  Committee 

NDI  Non-Developmental-Item 

OMB  Office  of  Manpower  and  Budget 

OSP  Other  Service  Program 

OT  Operational  Test 

P3I  Preplanned  Product  Improvement  Plan 

PDA  Principle  Development  Activity 

PEO  Program  Executive  Officer 

PLI  Position  Location  Information 

PLRS  Position  Location  Reporting  System 

PM  Program  Manager 

PNL  Pacific  Northwest  Laboratories 

POM  Program  Objective  Memorandum 

RD&S  Research,  Development,  and  Studies 

RDT&E  Research,  Development,  Testing,  and  Evaluation 

Ret  Retired 

RGS  Remote  Ground  Sensor 

ROC  Required  Operational  Capability 

RPV  Remotely  Piloted  Vehicle 

SAE  Service  Acquisition  Executive 

SBB  Switched  Backbone 

SCR  Single  Channel  Radio 

SDI  Strategic  Defense  Initiative 

SEMP  Systems  Engineering  Master  Plan 

SINCGARS  Single  Channel  Ground  and  Air  Radio  System 

SPA  WAR  Space  and  Naval  Warfare  Systems  Command 

SRI  Surveillance,  Reconnaissance,  and  Intelligence 

TACC  Tactical  Air  Command  Center 

TADC  Tactical  Air  Direction  Center 
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TADIL  Tactical  Digital  Information  Link 

TAO  Tactical  Air  Operations 

TAOC  Tactical  Air  Operations  Center 

TAOM  Tactical  Air  Operations  Module 

TAR  Tactical  Air  Request 

TCAC  Technical  Control  and  Analysis  Center 

ICO  Tactical  Combat  Operations  System 

TERPES  Tactical  Electronic  Reconnaissance  Processing  and  Evaluation 

System 

TESE  Tactical  Exercise  and  Simulation  System 

TIDP  Technical  Interface  Design  Plan 

TRSS  Tactical  Remote  Sensor  System 

TWAES  Tactical  Warfare  Analysis  and  Evaluation  System 

TWSEAS  Tactical  Warfare  Simulation,  Evaluation,  and  Analysis  System 

UCPS  Unit  Commander's  Personnel  System 

ULCS  Unit  Level  Circuit  Switch 

ULMS  Unit  Level  Message  Switch 

ULTDS  Unit  Level  Tactical  Data  Switch 

USA  United  States  Army 

USAF  United  States  Air  Force 

USMC  United  States  Marine  Corps 

USN  United  States  Navy 
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